System and method for delivering a therapeutic agent according to default infusion schedule

ABSTRACT

A fluid delivery system comprises a pump configured to deliver a therapeutic agent to a patient, a memory storing a therapy program defining the delivery of the therapeutic agent to the patient by the pump and a default infusion schedule based on the therapy program, and a processor configured to control the pump to deliver the therapeutic agent to the patient according to the therapy program, to determine an error condition that prevents the pump from continuing to deliver therapy according to the therapy program, and, upon determination of the error condition, to control the pump to deliver the therapeutic agent to the patient according to the default infusion schedule.

TECHNICAL FIELD

The disclosure relates generally to implantable fluid delivery devices.

BACKGROUND

Implantable fluid delivery devices are used to treat a number ofphysiological, psychological, and emotional conditions, includingchronic pain, tremor, Parkinson's disease, epilepsy, urinary or fecalincontinence, sexual dysfunction, obesity, spasticity, or gastroparesis.For some medical conditions, an implantable fluid delivery deviceprovides the best, and in some cases the only, therapy to restore apatient to a more healthful condition.

An implantable fluid delivery device typically provides a patient with aprogrammable dosage or infusion of a drug or other therapeutic agent.The fluid delivery device typically includes a reservoir, a fill port, apumping mechanism to pump the therapeutic agent from the reservoir, acatheter port to transport the therapeutic agent from the reservoir to apatient's anatomy, and electronics to control the pumping mechanism. Thefluid delivery device also typically includes some form of fluid flowcontrol in order to control or regulate the flow of the fluidtherapeutic agent from the reservoir to the fluid delivery device outletfor delivery of the therapeutic agent to a desired location within thepatient's body.

SUMMARY

In general, the disclosure relates to systems and methods of deliveringa therapeutic fluid to a patient according to a default infusionschedule via an implantable fluid delivery device.

In one example, a fluid delivery system comprises a pump configured todeliver a therapeutic agent to a patient, a memory storing a therapyprogram defining the delivery of the therapeutic agent to the patient bythe pump and a default infusion schedule based on the therapy program,and a processor configured to control the pump to deliver thetherapeutic agent to the patient according to the therapy program, todetermine an error condition that prevents the pump from continuing todeliver therapy according to the therapy program, and, upondetermination of the error condition, to control the pump to deliver thetherapeutic agent to the patient according to the default infusionschedule.

In another example, a method comprises determining a default infusionschedule based on a therapy program that defines delivery of atherapeutic agent to a patient by an implantable fluid delivery device,storing the default infusion schedule on a memory of the implantablefluid delivery device, determining if an error condition is present inthe implantable fluid delivery device such that the device cannotcontinue delivering therapy according to the therapy program, and if theerror condition is present, delivering the therapeutic agent accordingto the default infusion schedule.

In yet another example, a computer-readable medium includes instructionsfor causing a programmable processor to determine a default infusionschedule based on a therapy program that defines delivery of atherapeutic agent to a patient by an implantable fluid delivery device,store a default infusion schedule based on a therapy program thatdefines delivery of a therapeutic agent to a patient by an implantablefluid delivery device on the computer-readable medium, determine if anerror condition is present in the implantable fluid delivery device suchthat the device cannot continue delivering therapy according to thetherapy program, and if the error condition is present, deliver thetherapeutic agent according to the default infusion schedule.

In another example, a fluid delivery system comprises means fordelivering a therapeutic agent to a patient, means for storing a therapyprogram defining the delivery of the therapeutic agent to the patient bythe means for delivering the therapeutic agent, means for storing adefault infusion schedule based on the therapy program, and means forcontrolling the means for delivering the therapeutic agent to thepatient, means for determining an error condition that prevents themeans for delivering the therapeutic agent to the patient fromcontinuing to deliver therapy according to the therapy program, whereinthe means for controlling the means for delivering the therapeutic agentto the patient directs delivery of the therapeutic agent to the patientaccording to the default infusion schedule when the means fordetermining an error condition determines that the error condition ispresent.

The details of one or more embodiments of the invention are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription and drawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a conceptual diagram illustrating an example of a fluiddelivery system, which includes an implantable fluid delivery devicewith a medical pump that is configured to deliver a therapeutic agent toa patient via a catheter.

FIG. 2 is functional block diagram illustrating an example fluiddelivery device with a medical pump.

FIG. 3 is a functional block diagram illustrating an exampleprocessor-controlled memory that may be included in an implantable fluiddelivery device.

FIG. 4 is a functional block diagram illustrating exampleprocessor-controlled memory and hardware-controlled memory within animplantable fluid delivery device.

FIG. 5 is a diagram illustrating an example infusion schedule of atherapy program for the patient wherein an infusion pattern is repeateddaily.

FIG. 6 is a diagram illustrating another example infusion schedule of atherapy program for the patient wherein each day comprises a differentinfusion pattern.

FIG. 7 is a diagram illustrating an example infusion history for thepatient who had been prescribed the infusion schedule of FIG. 6.

FIG. 8 is a flowchart showing a method of storing and using a defaultinfusion schedule based on a therapy program of the patient.

FIG. 9 is a diagram illustrating an example default infusion schedulebased on the infusion schedule shown in FIG. 6.

FIG. 10 is a flowchart showing a first example method of storing thedefault infusion schedule in a backup memory and detecting an errorcondition within an implantable fluid delivery device.

FIG. 11 is a flowchart showing a second example method of storing thedefault infusion schedule in a backup memory and detecting an errorcondition within an implantable fluid delivery device.

FIG. 12 is a flowchart showing a third example method of storing thedefault infusion schedule in a backup memory and detecting an errorcondition within an implantable fluid delivery device.

FIG. 13 is a flowchart showing a fourth example method of storing thedefault infusion schedule in a backup memory and detecting an errorcondition within an implantable fluid delivery device.

DETAILED DESCRIPTION

The electronics of an implantable fluid delivery device may include aprocessor and other associated hardware to provide a prescribed dosageof a drug or other therapeutic agent under a set time schedule and underspecified treatment parameters. The fluid delivery device may alsoinclude some form of memory, such as a Random Access Memory (RAM),Read-Only Memory (ROM), and/or a non-volatile memory such as EEPROM orFlash memory, for storing information regarding the control of thepumping mechanism, including treatment parameters such as a dosageinfusion schedule. The fluid delivery device may also include hardwarememory, such as hardware memory in an application specific integratedcircuit (ASIC) or other integrated circuit (IC). Typically, treatmentparameters, such as dosage rate and timing prescribed by a clinician areentered into the fluid delivery device using an external device commonlyreferred to as a physician, or clinician, programmer. The programmer maycommunicate with the fluid delivery device by telemetry in order toallow the clinician to program the fluid delivery device and todetermine how the fluid delivery device is operating at any given time.The clinician can also use the programmer to change the treatmentparameters, such as medication infusion rate or an infusion schedules.

Once the fluid delivery device is implanted in a patient, however, anumber of complications may occur that affect the ability of the deviceto reliably deliver therapy to a patient. For example, the fluiddelivery device memory that stores treatment parameters for drugdelivery may become corrupted. Memory corruption can occur for severalreasons. For example, memory corruption can be caused by a temporarydrop in the battery voltage of the fluid delivery device power source,e.g., due to Electro-Magnetic Interference (EMI) or an internal powersurge, software execution malfunctions, e.g., a bug or bit flip withinthe processor or memory, such as bit flip errors due to EMI or exposureto radiation or cosmic rays, that causes an erroneous program execution,or latent memory cell failures in which a memory cell loses its abilityto hold programmed values over time. In some cases, if the memory iscorrupted, the fluid delivery device may not be able to operate untilthe fluid delivery device is reprogrammed. This is undesirable becausethe patient will lose treatment therapy with the therapeutic agent untilreprogramming is completed, which may result in the return of symptomsfor the patient and, in some cases, may cause the patient to go intowithdrawal.

In general, this disclosure is directed to techniques for providing animplantable fluid delivery device with a default infusion schedule thatis determined based on a patient-specific and/or therapeuticagent-specific therapy program by which the device can continue todeliver the therapeutic agent to the patient when it is determined thatan error condition exists that prevents continuing with the treatmentinfusion schedule defined by the therapy program. In this way, the fluiddelivery device stores a therapy program defining delivery of atherapeutic agent to a patient under normal operating conditions onto amain memory on the fluid delivery device, as well as a backup defaultinfusion schedule on a backup memory of the fluid delivery device thatenables the fluid delivery device to continue delivering a therapeuticamount of the therapeutic agent to the patient even when an errorcondition would typically require the fluid delivery device to beshutdown.

An implantable fluid delivery device may be configured to deliver atherapeutic agent from a fluid reservoir to a patient according to atherapy program, which may, for example, specify a delivery rate of afluid delivered to the patient by the fluid delivery device. As anotherexample, a therapy program may adjust the delivery rate automaticallybased on physiological characteristics of a patient. In some instances,an external controller may be used to alter the therapy program as wellas send and receive data relating to the operation of the fluid deliverydevice. In different examples, an external programmer may be operated byeither one or both of a clinician and the patient.

FIG. 1 is a schematic diagram of an example system 10, including animplantable fluid delivery device, also referred to as an implantablemedical device (IMD) 12, which is configured to deliver a therapeuticagent, such as a pharmaceutical agent, for example a drug, insulin, painrelieving agent, anti-inflammatory agent, gene therapy agent, or thelike, to a target site 2 within a patient 1. In this manner, IMD 12functions as an implantable fluid delivery device. The therapeutic agentis delivered via a catheter 14 that is coupled to IMD 12. Catheter 14may comprise a plurality of catheter segments, or catheter 14 may be aunitary catheter. In the example shown in FIG. 1, target site 2 isproximate to spinal cord 4 of patient 1.

A proximal end 16 of catheter 14 is coupled to IMD 12 while a distal end18 of catheter 14 is positioned proximate target site 2. System 10 mayalso include an external programmer 20 that communicates with IMD 12 asneeded, such as to provide or retrieve therapy information or othertreatment parameters associated with therapy delivery. For example,external programmer 20 may be configured to turn IMD 12 on or off, todeliver the initial therapy parameters for patient 1, to modify thetherapy parameters, and so forth. In one example, external programmer 20communicates with pump wirelessly 22, as shown in FIG. 1.

Although patient 1 is generally referred to as a human patient in thepresent disclosure, system 10 can be used with other mammalian ornon-mammalian patients. IMD 12 may be employed to treat, manage orotherwise control various conditions or disorders of patient 1,including, e.g., pain (e.g., chronic pain, post-operative pain orperipheral and localized pain), tremor, movement disorders (e.g.,Parkinson's disease), diabetes, epilepsy, neuralgia, chronic migraines,urinary or fecal incontinence, sexual dysfunction, obesity,gastroparesis, mood disorders, or other disorders.

IMD 12 may be configured to deliver one or more therapeutic agents,alone or in combination with other therapies, including, e.g.,electrical stimulation. For example, in some cases, a medical pump maydeliver one or more pain-relieving drugs to patients with chronic pain,insulin to a patient with diabetes, or other fluids to patients withdifferent disorders. IMD 12 may be implanted in patient 1 for chronic ortemporary therapy delivery.

IMD 12 includes an outer housing 24 that is constructed of abiocompatible material that resists corrosion and degradation frombodily fluids, such as titanium or biologically inert polymers. IMD 12may be implanted within a subcutaneous pocket close to target 2. Forexample, as shown in FIG. 1, IMD 12 may be implanted within the abdomenof patient 1 close to the position along spinal cord 4 where target site2 is located. In other examples, IMD 12 may be implanted within othersuitable sites within patient 1, which may depend, for example, on wheretarget site 2 is located within patient 1, and the ease of implantingIMD 12 within suitable locations near site target 2. IMD 12 may also beexternal to patient 1 with a percutaneous catheter connected between IMD12 and the target delivery site 2 within the patient.

Catheter 14 may be coupled to IMD 12 either directly or with the aid ofa catheter extension (not shown). In the example shown in FIG. 1,catheter 14 traverses from the implant site of IMD 12 to target site 2proximate to spinal cord 4. Catheter 14 is positioned such that one ormore fluid delivery outlets of catheter 14 are proximate to the one ormore locations at target site 2 within patient 1. IMD 12 delivers atherapeutic agent to the target site 2 proximate to spinal cord 4 withthe aid of catheter 14. For example, IMD 12 may be configured forintrathecal drug delivery into the intrathecal space or epidural spacesurrounding spinal cord 4.

In some examples, multiple catheters 14 may be coupled to IMD 12 totarget the same or different tissue or nerve sites within patient 1.Thus, although a single catheter 14 is shown in FIG. 1, in otherexamples, system 10 may include multiple catheters or catheter 14 maydefine multiple lumens for delivering different therapeutic agents topatient 1 or for delivering a therapeutic agent to different tissuesites within patient 1. Accordingly, in some examples, IMD 12 mayinclude a plurality of reservoirs for storing more than one type oftherapeutic agent. In some examples, IMD 12 may include a single longtube that contains the therapeutic agent in place of a reservoir.However, for ease of description, an IMD 12 including a single reservoiris primarily discussed herein with reference to the example of FIG. 1.

IMD 12 may deliver one or more therapeutic agents to patient 1 accordingto one or more therapy programs. Example therapeutic agents that IMD 12may be configured to deliver include insulin, morphine, hydromorphone,bupivacaine, clonidine, other analgesics, genetic agents, antibiotics,nutritional fluids, analgesics, hormones or hormonal drugs, gene therapydrugs, anticoagulants, cardiovascular medications or chemotherapeutics.A therapy program, generally speaking, may set forth different therapyparameters, such as an infusion schedule specifying programmed doses,dose rates for the programmed doses, and specific times to deliver theprogrammed doses.

The therapy programs may be a part of a program group for therapy,wherein the group includes a plurality of constituent therapy programsand/or infusion schedules. In some examples, IMD 12 may be configured todeliver a therapeutic agent to patient 1 according to different therapyprograms on a selective basis. IMD 12 may include a memory to store oneor more therapy programs, instructions defining the extent to whichpatient 1 may adjust therapy parameters, switch between therapyprograms, or undertake other therapy adjustments. Patient 1 may selectand/or generate additional therapy programs for use by IMD 12 viaexternal programmer 20 at any time during therapy or as designated bythe clinician.

Programmer 20 is an external computing device that is configured towirelessly communicate with IMD 12. For example, programmer 20 may be aclinician programmer that the clinician uses to communicate with IMD 12.Alternatively, programmer 20 may be a patient programmer that allowspatient 1 to view and modify therapy parameters. The clinicianprogrammer may include additional or alternative programming features,relative to the patient programmer. For example, more complex orsensitive tasks may only be allowed by the clinician programmer toprevent patient 1 from making undesired changes to the operation of IMD12.

Programmer 20 may be a hand-held computing device that includes adisplay viewable by the user and a user input mechanism that can be usedto provide input to programmer 20. For example, programmer 20 mayinclude a processor 26, a display screen (e.g., a liquid crystal displayor a light emitting diode display) that presents information to theuser. In addition, programmer 20 may include a keypad, buttons, aperipheral pointing device, touch screen, voice recognition, or anotherinput mechanism that allows the user to navigate though the userinterface of programmer 20 and provide input. Processor 26 can includeone or more processors, including one or more microprocessors, digitalsignal processors (DSPs), application specific integrated circuits(ASICs), field programmable gate arrays (FPGAs), or any other equivalentintegrated or discrete logic circuitry, as well as any suitablecombination of such components. The term “processor” or “processingcircuitry” may generally refer to any of the foregoing logic circuitry,alone or in combination with other logic circuitry, or any otherequivalent circuitry.

In other examples, rather than being a handheld computing device or adedicated computing device, programmer 20 may be a larger workstation ora separate application within another multi-function device. Forexample, the multi-function device may be a cellular phone, personalcomputer, laptop, workstation computer, or personal digital assistantthat can be configured to an application to simulate programmer 20.Alternatively, a notebook computer, tablet computer, or other personalcomputer may execute an application to function as programmer 20, e.g.,with a wireless adapter connected to the personal computer forcommunicating with IMD 12.

When programmer 20 is configured for use by the clinician, programmer 20may be used to transmit initial programming information to IMD 12. Thisinitial information may include hardware information for system 10 suchas the type of catheter 14, the position of catheter 14 within patient1, the type of therapeutic agent(s) delivered by IMD 12, a baselineorientation of at least a portion of IMD 12 relative to a referencepoint, therapy parameters of therapy programs stored within IMD 12 orwithin programmer 20, and any other information the clinician desires toprogram into IMD 12.

The clinician uses programmer 20 to program IMD 12 with one or moretherapy programs that define the therapy delivered by IMD 12 to patient1. During a programming session, the clinician may determine one or moretherapy programs that provide effective therapy to patient 1. Patient 1may provide feedback to the clinician as to the efficacy of a specifictherapy program being evaluated or desired modifications to the therapyprogram. Once the clinician has identified one or more programs that maybe beneficial to patient 1, the patient may continue the evaluationprocess and determine which of these programs best alleviates thecondition of or otherwise provides efficacious therapy to the patient.Programmer 20 may assist the clinician in the creation/identification oftherapy programs by providing a methodical system of identifyingpotentially beneficial therapy parameters.

A therapy program may set forth a number of therapy parameters, e.g.,different predetermined dosages of the therapeutic agent, the infusionrate of delivery of one or more of the therapeutic agent doses, a timeinterval between successive patient-initiated boluses (e.g., a lock-outinterval), a maximum dose that may be delivered over a given timeinterval, and so forth. IMD 12 may include a feature that preventsdosing the therapeutic agent in a manner inconsistent with the therapyprogram. A dosage of a therapeutic agent may be expressed as an amountof the agent, e.g., measured in microliters, micrograms (mcg), or othervolumetric or mass units provided to the patient over a particular timeinterval, e.g., per day or twenty-four hour period. This dosage amountmay convey to the caregiver an indication of the probable efficacy ofthe therapeutic agent and the possibility of side effects of the agent.In general, a sufficient amount of the therapeutic agent should beadministered in order to have a desired therapeutic effect, such as painrelief. However, the amount of the therapeutic agent administered to thepatient may be limited to a maximum amount, such as a maximum dailydose, in order to avoid potential side effects. Program informationspecified by a user via programmer 20 may be used to control dosageamount, dosage rate, dosage time, maximum dose for a given time interval(e.g., daily), or other parameters associated with delivery of a drug orother therapeutic agent by IMD 12. The therapy program may also includea specific infusion schedule, wherein the infusion rate of thetherapeutic agent for specific times and for specific time periods isset for patient 1. Examples of infusion schedules are described belowwith respect to FIGS. 5 and 6.

In some cases, programmer 20 may be configured for use by patient 1.When configured as a patient programmer, programmer 20 may have limitedfunctionality in order to prevent patient 1 from altering criticalfunctions or applications that may be detrimental to patient 1. In thismanner, programmer 20 may only allow patient 1 to adjust certain therapyparameters or set an available range for a particular therapy parameter.In some cases, a patient programmer may permit the patient to controlIMD 12 to deliver a supplemental, patient bolus or rate change, ifpermitted by the applicable therapy program administered by the IMD,e.g., if delivery of the patient bolus or rate change would not violatea lockout interval or maximum dosage limit. Programmer 20 may alsoprovide an indication to patient 1 when therapy is being delivered, whenIMD 12 needs to be refilled, or when the power source within programmer20 or IMD 12 needs to be replaced or recharged.

Whether programmer 20 is configured for clinician or patient use,programmer 20 may communicate with IMD 12 or any other computing devicevia wireless communication link 22. Programmer 20, for example, maycommunicate via wireless communication link 22 with IMD 12 using radiofrequency (RF) telemetry techniques. Programmer 20 may also communicatewith another programmer or computing device via a wired or wirelessconnection using any of a variety of local wireless communicationtechniques, such as RF communication according to the 802.11 orBluetooth specification sets, ZigBee communication standards, infrared(IR) communication according to the IRDA specification set, or otherstandard or proprietary telemetry protocols. Programmer 20 may alsocommunicate with another programmer or computing device via exchange ofremovable media, such as magnetic or optical disks, or memory cards orsticks. Further, programmer 20 may communicate with IMD 12 and anotherprogrammer via remote telemetry techniques, or via a network, such asthe internet, a local area network (LAN), a wide area network (WAN), apublic switched telephone network (PSTN), or a cellular telephonenetwork. IMD 12 may also communicate with another computing device, suchas another programmer or an intermediate device such as a homemonitoring device. IMD 12 may communicate with the other computingdevice wirelessly, similar to wireless communication 22 with programmer20, or through a network, such as the internet, a local area network(LAN), a wide area network (WAN), a public switched telephone network(PSTN), or a cellular telephone network. In one example, IMD 12 isconnected wirelessly to an interim network device that is connected tothe network in order to communicate with the other computing device.

FIG. 2 is a functional block diagram illustrating components of anexample IMD 12, which may include a refill port 30, a reservoir 32, aprocessor 34, a memory, such as processor-controlled memory 36 andhardware-controlled memory 56, a telemetry module 38, a power source 40,a medical pump 42, a hardware controller 44, internal channels 46, and acatheter access port 48. Medical pump 42 may be any mechanism thatdelivers a therapeutic agent in some metered or other desired flowdosage to target site 2 within patient 1 from reservoir 32 via thecatheter 14. Examples of medical pump 42 include a peristaltic pump thatuses rollers or other actuation devices to move fluid along a pump tubeand a piston pump where a piston pushes fluid from the pump. Refill port30 may comprise a self-sealing injection port. The self-sealinginjection port may include a self-sealing membrane to prevent loss oftherapeutic agent delivered to reservoir 32 via refill port 30. After adelivery system, e.g., a hypodermic needle, penetrates the membrane ofrefill port 30, the membrane may seal shut when the needle is removedfrom refill port 30. Internal channels 46 includes one or more segmentsof tubing or a series of cavities that run from reservoir 32, around orthrough medical pump 42 to catheter access port 30. IMD 12 may alsoinclude an alarm 49 that is used to alert the patient of a conditionwithin IMD 12, such as the detection of an error condition and/or thestart of using default infusion schedule 70. As described in more detailbelow, default infusion schedule 70 provides a backup or last-resortinfusion schedule that can be used to maintain infusion of at least aminimum therapeutic amount of the therapeutic agent to patient 1 until aphysician or other clinician is able to reprogram IMD 12.

Processor 34 controls the operation of medical pump 42 with the aid ofsoftware instructions associated with program information that is storedin memory 36. In one example, processor 34 is configured to run thesoftware instructions in order to control operation of fluid deliverydevice 12. The software instructions may define therapy programs thatspecify the amount of a therapeutic agent that is delivered to a targettissue site within patient 1 from reservoir 32 via catheter 14, e.g.,dose, the rate at which the agent is delivered, e.g., dosage rate, andthe time at which the agent will be delivered and the time interval overwhich the agent will be delivered, e.g., the infusion schedule for doseor doses defined by program. In other examples, a quantity of the agentmay be delivered according to one or more physiological characteristicsof a patient, e.g., physiological characteristics sensed by one or moresensors (not shown) implanted within a patient as part of therapy system10 (FIG. 1). Processor 34 can include one or more processors, includingone or more microprocessors, digital signal processors (DSPs),application specific integrated circuits (ASICs), field programmablegate arrays (FPGAs), or any other equivalent integrated or discretelogic circuitry, as well as any suitable combination of such components.The term “processor” or “processing circuitry” may generally refer toany of the foregoing logic circuitry, alone or in combination with otherlogic circuitry, or any other equivalent circuitry.

Processor-controlled memory 36 may include any volatile or non-volatilemedia, such as a random access memory (RAM), read only memory (ROM),non-volatile RAM (NVRAM), electrically erasable programmable ROM(EEPROM), flash memory, and the like. As mentioned above, memory 36 maystore program information including instructions for execution byprocessor 34, such as, but not limited to, therapy programs, historicaltherapy programs, timing programs for delivery of the therapeutic agentfrom reservoir 32 to catheter 14, and any other information regardingtherapy of patient 1. In one example, shown in FIG. 2, memory 36includes a ROM portion 50, a RAM portion 52, and a flash memory portion54. Memory 36 may include separate memory portions for storinginstructions, patient information, therapy parameters (e.g., groupedinto sets referred to as “dosing programs”), therapy adjustmentinformation, program histories, and other categories of information suchas any other data that may benefit from separate physical memorymodules. For example, software instructions may be stored on ROM 50and/or flash memory 54, while therapy parameters or adjustmentinformation may be stored on RAM 52. Multiple copies of each of theforegoing types of information may be stored in different memoryportions within memory 36 for redundancy or backup of the information.

Hardware controller 44 may directly control the hardware of medical pump42. Hardware controller 44 receives instructions regarding the deliveryof therapeutic agent from processor 34, such as an infusion ratecorresponding to a therapy program stored in memory 36, and controlsmedical pump 42 accordingly. For example, if a therapy program 64 storedin memory 36, described in more detail below, dictates that at aparticular point in time, IMD 12 should be delivering a particulardosage rate of the therapeutic agent to patient 1, processor 34instructs hardware controller 44 to provide the particular dosage rate,and hardware controller 44 causes the actuating device of medical pump42, such as rollers in a peristaltic pump or a piston in a piston pump,to be actuated at the rate that will provide the particular dosage rate.Hardware controller 44 can include one or more processors, including oneor more microprocessors, digital signal processors (DSPs), applicationspecific integrated circuits (ASICs), field programmable gate arrays(FPGAs), or any other equivalent integrated or discrete logic circuitry,as well as any suitable combination of such components. The term“controller” may generally refer to any of the foregoing logiccircuitry, alone or in combination with other logic circuitry, or anyother equivalent circuitry. Hardware controller 44 may also include ahardware-controlled memory 56 that stores parameters associated withcontrol of medical pump 42, for example trim parameters such as voltagereferences and bias currents. Hardware-controlled memory 56 may includeany volatile or non-volatile media, such as hardware registers randomaccess memory (RAM), read only memory (ROM), non-volatile RAM (NVRAM),electrically erasable programmable ROM (EEPROM), flash memory, hardwareregisters and the like.

Telemetry module 38 in IMD 12, as well as telemetry modules inprogrammers, such as external programmer 20, provides communicationbetween IMD 12 and external programmer 20. Communication with telemetrymodule 38 may be accomplished by any communication mechanism, such aslocal wireless communication techniques including, but not limited to,RF communication according to the 802.11 or Bluetooth specificationsets, ZigBee communication standards, infrared (IR) communicationaccording to the IRDA specification set, or other standard orproprietary telemetry protocols. In addition, telemetry module 38 maycommunicate with programmer 20 via proximal inductive interaction of IMD12 with external programmer 20. Processor 34 controls telemetry module38 to send from and receive information to IMD 12.

Power source 40 delivers operating power to various components of IMD12. Power source 40 may include a small rechargeable or non-rechargeablebattery and a power generation circuit to produce the operating power.In the case of a rechargeable battery, recharging may be accomplishedthrough proximal inductive interaction between an external charger andan inductive charging coil within IMD 12. In some examples, powerrequirements may be small enough to allow IMD 12 to utilize patientmotion and implement a kinetic energy-scavenging device to tricklecharge a rechargeable battery. In other examples, traditional batteriesmay be used for a limited period of time. As a further alternative, anexternal inductive power supply could transcutaneously power IMD 12whenever measurements are needed or desired.

Alarm 49 alerts the patient of a condition within IMD 12, such as thedetection of an error condition and/or the use of default infusionschedule 70 to deliver the therapeutic agent. Alarm 49 may be any devicethat may come to a patient or clinicians attention such as an audiblealarm that is heard by the patient, a vibrational alarm that is felt bythe patient, or a signal sent by IMD 12 to another device, such as anexternal computing device, for example programmer 20.

In general, IMD 12 includes memory including a main memory portion and abackup memory portion. The terms “main memory” and “backup memory” arenot meant to be limiting, but rather are intended to provide clarity. Ingeneral, the main memory portion may include data, instructions, orparameters that may be considered to be used as part of the normaloperation of IMD 12 while the backup memory portion may include data,instructions, and parameters that provide redundancy or backup of thenormal operation of IMD 12. However, anything described as being storedin a portion of memory designated “main memory” herein can also bestored in a portion of memory referred to herein as “backup memory” andvice versa. In addition, data may be redundantly stored in both aportion labeled as “main memory” herein and in a portion labeled “backupmemory.” In the example of FIG. 2, processor-controlled memory 36includes main memory 60 and backup memory 62. However, as illustrated inFIGS. 3 and 4, in other examples, the main memory and backup memoryincluded in the memory of IMD 12 may be allocated to different specificmemory components, e.g., split between processor-controlled memory 36and hardware-controlled memory 56. Additionally, in the example shown inFIG. 2, main memory 60 is a portion of RAM 52 of processor-controlledmemory 36, however, different types of memory of theprocessor-controlled memory 36, e.g., ROM 50 or flash memory 54, mayalso be used as main memory 60. As with main memory 60, although backupmemory 62 is a portion of flash memory 54 of processor-controlled memory36 in the example of FIG. 2, different types of memory, e.g., a portionof RAM 52 or ROM 50 of the processor-controlled memory 36 or hardwareregisters 58 or another component of hardware-controlled memory 56 maybe used as backup memory 62.

The main memory and backup memory may be part of the same type ofmemory, such as main memory 60 and backup memory 62A both being a partof RAM 52 as in the example of FIG. 3. In such an example, the mainmemory and the backup memory may each be part of a separate memory,e.g., a separate memory chip or different sections of the same memorychip, or the main memory and the backup memory may merely be separateportions of the same memory.

In FIG. 2, therapy program 64 corresponding to the delivery of atherapeutic agent to patient 1 is stored in main memory 60. The therapyprogram may also be stored in backup memory 62, such as to providestorage redundancy. Default infusion schedule 70 is stored in backupmemory 62. The default infusion schedule may also be stored in mainmemory 60 as well as backup memory 62, such as to provide storageredundancy. Default infusion schedule 70 is based on therapy program 64for patient 1 such that default infusion schedule 70 is specific topatient 1, IMD 12, and/or the therapeutic agent being delivered by thedevice to the patient. An identifier (not shown) may be stored in orderto identify default infusion schedule 70 to a particular time orinfusion schedule. For example, if therapy program 64 includes aschedule with different infusion patterns each day, such as infusionschedule 74 described below with respect to FIG. 6, then at thebeginning of each day, processor 34 may store the identifier to indicatewhich day it is, so that if an error condition is detected, processorwill be able to know on which day of a corresponding default infusionschedule 70 to start. For example, on Day 1 of therapy program 74, whichmay be a Monday, processor 34 may store an identifier indicating that itis Day 1. If no error condition occurs during Day 1, then at the startof Day 2, processor 34 may store a new identifier, replacing theprevious identifier that indicates it is Day 2. However, if an errorcondition does occur during Day 1, then when IMD 12 reverts to defaultinfusion schedule 70, it will start infusion at the beginning of Day 1of default infusion schedule 70. Periods of time other than full daysmay be used with the identifier, such as hourly, every eight hours,every 12 hours, every 16 hours, every 20 hours, and so on. In oneexample, the identifier is stored in backup memory 62 along with defaultinfusion schedule 70.

An error-detection check, such as a cyclic redundancy check (CRC), mayalso be provided in order to check for data corruption or other errorswithin therapy program 64 and default infusion schedule 70. In oneexample, a first CRC is stored in main memory 60 to check for datacorruption or other errors within therapy program 64 while a second CRCis stored in backup memory 62 to check for data corruption or othererrors within default infusion schedule 70. In one example, a CRC isstored along with the data that it will check for data corruption orother errors, such as storing the first CRC in the same location withinmain memory 60 as therapy program 64 and storing the second CRC in thesame location within backup memory 62 as default infusion schedule 70.Processor 34 of IMD 12 is configured to determine an error conditionwithin IMD 12 that prevents the continued use of therapy program 64without unnecessary risk to patient 1, and upon determining theexistence of such an error condition, to cease using therapy program 64and to instead use default infusion schedule 70 for delivery of thetherapeutic agent to patient 1.

An error condition that prevents the reliably use of therapy program 64may be any error that either causes the stored therapy program to beunreliable or that renders IMD 12 unable to reliably implement thestored therapy program. An example of such an error condition is therapyprogram 64 being corrupted in main memory 60. If therapy program 64 isredundantly stored in other memories, such as backup memory 62, than anerror condition would not exist unless there is corruption in theredundantly stored copies as well.

Another example of an error condition is IMD 12 losing its time pointwhen therapy program 64 includes a time-varying infusion schedule. Aloss of time point may comprise a total loss of time point, wherein IMD12 is unable to determine the present time and is unable to reliablymeasure the passage of time after the loss of the present time point, ora partial loss of time point, wherein IMD 12 does not know the presenttime, but can reliably keep track of time going forward. A total loss oftime point may occur, for example, if the device that is used to measuretime within IMD 12, such as an oscillator circuit, for example a crystaloscillator, becomes corrupt or unreliable such that IMD 12 cannotreliably measure the passage of time. A partial loss of time may involvean error wherein the present time is lost for some reason, but whereinthe time-measuring device is still reliable.

In one example, IMD 12 may include two or more independenttime-measuring devices, also referred to as a time reference or timeorigin, that may be cross-checked to provide redundancy of time keeping.For example, IMD 12 may comprise two separate time-keeping devices thatrun independent from one another, such as two separate oscillatorcircuits, for example two separate crystal oscillators or two separateelectrical oscillator circuits or processors. A first time-keepingdevice is used by processor 34 as the primary device to direct infusionof the therapeutic agent according to an infusion schedule of therapyprogram 64. After certain time frequencies, processor 34 may compare thetime values of the first time-keeping device and the second time-keepingdevice and determine if they are still in sync, within a predeterminedthreshold. In one example, processor 34 may compare the time values fromeach time-keeping device between about every on-thousandth of a secondand about every day, such as every second, every minute, every fifteenminutes, every thirty minutes, every hour, every two hours, every fourhours, every twelve hours, etc. If processor 34 discovers that the twotime-keeping devices are in sync, then processor 34 can be confidentthat there is no loss in time point. If the time-keeping devices are outof sync, processor 34 may update an errant time-keeping device with thecorrect time point. In one example, processor 34 analyzes eachtime-keeping device to determine if there is an error with one of themthat explains the out-of-sync finding. If processor 34 determines thatonly one time-measuring device is in error, and can determine whichtime-measuring device has the error, it reinitializes the erranttime-measuring device to the correct time point using the other,non-errant, device. If processor 34 either determines that bothtime-measuring devices are in error or cannot determine whichtime-measuring device is in error, then processor 34 determines thatthere is a loss of time point that requires reversion to defaultinfusion schedule 70. In one example, whenever processor 34 checks ifthe time-keeping devices are synchronized, processor 34 sets asynchronization marker so that if processor 34 has any reason to doubtthe reliability of the time point provided by the primary time-keepingdevice, then processor 34 will determine the amount of time that haselapsed since the last synchronization check as measured by the secondtime-keeping device to determine what point in time processor 34 mayresume using an infusion schedule of therapy program 64. Additionaltime-measuring devices, such as additional oscillator circuits, forexample oscillator crystals or electrical oscillator circuits orprocessors, may be used beyond just two such devices. For example, IMD12 may include three, four, five, or more time-measuring devices.

Another example error condition includes therapy program 63 failing aruntime check, such as a parameter within therapy program 64 being outof bounds or a parameter pointing to an invalid or unused spaced withintherapy program 64 that may be due to a programmer error when encodingtherapy program 64. Other example error conditions include softwareerrors, e.g., errant pointers, memory corruption, or stack overflow,that cause reinitializing of IMD 12, at which point IMD 12 is unable todeliver a time-varying infusion schedule. In one example, any error orcorruption within IMD 12 that may be interpreted as corresponding to aloss or corruption of time point may be considered an error conditionthat warrants the use of default infusion schedule 70. Examples of sucherrors or corruptions include detection of a stack overflow, an errantpointer that may have caused random writes to memory or random memorycorruption if the random writing or corruption is believed to haveincluded a memory area that maintains time point, program code goingdown an unexpected path (e.g., into a default statement of a switch typeconstruct where based on normal execution, the code should not gothrough a default case, or in a else clause where one is not valid), anexception thrown by code, memory allocation or deallocation errors, andgeneral memory management issues.

Another example error condition may occur when, following an unexpectedpump reset, IMD 12 is unable to deliver the therapy program, inparticular a time-varying infusion program. During operation of IMD 12,an error or corruption may occur that requires the reset of the hardwareof IMD 12. If the error or corruption is detected by IMD 12, such as byprocessor 34, then the reset may be a “planned” reset, wherein processor34 stores a log of the error or corruption so that after the reset,processor 34 may read the log and know exactly what caused the reset.However, in some cases, IMD 12 may reset for an unknown reason such thatno log of the error was made. In such a case, processor 34 may not knowand may be unable to determine what caused the unexpected reset, and inorder to ensure patient safety, processor 34 may assume that the errorthat caused the unexpected reset is one wherein implementation of thestored therapy program would be unreliable, such that processor 34determines that the default infusion schedule 70 should be used instead.Examples of pump resets that may be considered error conditions forpurposes of the present disclosure include (a) a pump reset wherein theerror or problem that caused the reset is known or discoverable byprocessor 34, but wherein the error or problem cannot be correctedwithout reprogramming IMD 12; and (b) a pump reset wherein the error orproblem that caused the reset is unknown, e.g., an unexpected reset,wherein it is assumed that the error or problem is serious enough thatdelivery according to therapy program 64 may be unreliable because ofthe unknown nature of the error.

Other example error conditions occur when pump hardware, such ashardware controller 44, determines that processor 34 or the pumpsoftware is not functioning correctly. One example of this type of errorcondition is a failure in the timing or another defined parameter of thecommunication between processor and hardware controller 44, e.g., animproper handshake between processor 34 and hardware controller 44.Another example of an error condition of a malfunctioning processor 34or pump software is a failure of a crosschecking between hardware andsoftware of fluid delivery device 12, such as an incorrect strobing of awatchdog timer associated with hardware controller 44, wherein processor34 fails to communicate with the watchdog timer at a predetermined,repeating time interval, e.g., processor 34 fails to “strobe” thewatchdog timer. Mechanisms other than handshaking or a watchdog timermay be used to crosscheck between hardware controller 44 and processor34.

Another example error condition is a detection, e.g., by processor 34,of a possible malicious attempt by an external programmer that couldharm patient 1. Processor 34 may be configured to determine that anexternal programmer that is attempting to modify the therapy program onfluid delivery device 12 is an unauthorized external programmer.Processor 34 may also be configured to determine that changes made tothe therapy program, even if by an authorized external programmer, aremalicious such that processor 34 determines it should revert to a safe,default infusion schedule, e.g., stored in the backup memory 62.

Another error condition is the determination by processor 34 thatparameters provided by therapy program 64 stored in memory 36 areincorrect, inconsistent, or invalid. Examples of incorrect parametersinclude a provided parameter being outside of general boundariesspecified by therapy program 64 or IMD 12 or that the provided parameterconflicts with another parameter provided by therapy program 64. Forexample, therapy program 64 may specify boundaries such that aparticular parameter may only have values between 0 and 200, but mayalso provide a specific instruction that, when encoded in an 8-bitnumber, comes to a value of 216. In another example, therapy program 64may indicate that it includes a weekly infusion schedule (bounded as aseven day schedule) that includes eight days. In such a case, theconflict between the boundaries and the specific instruction may bedetermined to be an error condition that results in processor 34determining that default infusion schedule 70 should be used. Examplesof inconsistent parameters include those resulting in conflictinginformation, such as two parameters that cannot coexist, or conflictinginstructions, such as two instructions that cannot both be executed.Examples of invalid parameters, or an invalid therapy program 64,include encoding of a therapy program 64 that shows it should be run,but the therapy program 64 has not been initialized or it has beeninvalidated.

Yet another error condition may be a pump stoppage having a durationlonger than a predetermined time. For example, fluid delivery device 12may be instructed by a clinician through external programmer 20 to stopthe therapy program to perform a procedure, such as refilling reservoir32 or a testing procedure of patient 1, such as a magnetic resonanceimaging (MRI) scan. Typically, fluid delivery device 12 is restartedafter the procedure is complete. The clinician may forget to restartfluid delivery device 12, however, and both patient 1 and the clinicianmay be unaware that fluid delivery device 12 is no longer infusing thetherapeutic agent. In another example, patient 1 may be taken off thetherapy provided by fluid delivery device 12 for an extended period oftime, such as for a week or a month while patient 1 is being treated foran infection that may be compromised by continued infusion of thetherapeutic agent delivered by fluid delivery device 12. Processor 34 orhardware controller 44 may be configured so that when an instruction tostop for a procedure or for an extended discontinuation of therapy isinitiated, an error condition is triggered when fluid delivery device isnot restarted after a predetermined period of time that is sufficientfor the procedure or discontinuation of therapy to be completed, e.g.,an hour or two hours after the instruction to stop for an MRI scan isprovided from external programmer 20 or after a discontinuation oftherapy continues for more than 24 hours beyond the time period planned.Once the predetermined period of time has elapsed, fluid delivery device12 will treat it as an error condition that necessitates use of adefault infusion schedule 70 to resume direct delivery of thetherapeutic agent.

The processor that is configured to determine the existence of an errorcondition may be one or more of any processor, microprocessor, digitalsignal processor (DSP), application specific integrated circuit (ASIC),field programmable gate array (FPGA), programmable logic circuit, or thelike, either alone or in any suitable combination, within IMD 12. In theexample shown in FIG. 2, the processor can be processor 34 or hardwarecontroller 44. For example, processor 34 may be configured to determinethe existence of any or all of the error conditions described above,such as a corruption of the therapy program 64 in memory 36 or a loss oftime point.

In another example, hardware controller 44 may be configured todetermine that processor 34 or software within IMD 12 is not functioningproperly, such as an incorrect timing of communication between processor34 and hardware controller 44 or incorrect strobing of a watchdog. Inanother example, both processor 34 and hardware controller 44 may beconfigured to determine the existence of error conditions. For example,processor 34 may be configured to detect error conditions in whichprocessor 34 is still functional, such as a corruption of the therapyprogram in memory 36 or a loss of time point, while hardware controller44 may be configured to detect error conditions in which processor 34 orIMD software are malfunctioning. In yet another example, processor 34 isconfigured to detect an error condition within IMD 12 and, upondetection, to instruct hardware controller 44 to use default infusionschedule 70. Hardware controller 44 is then responsible for changing IMD12 from the infusion schedule of therapy program 64 to default infusionschedule 70.

Therapy program 64 corresponds to the delivery of a specific therapeuticagent to a specific patient 1 and may include therapy parameters, asdescribed above, including therapeutic agent doses and dose rates.Therapy program 64 includes an infusion schedule to be used duringtherapy of patient 1, such as the example infusion schedules 72, 74shown in FIGS. 5 and 6. As shown in FIGS. 5 and 6, infusion schedules72, 74 may be time-varying such that the dosage rate that is deliveredto patient 1 varies over time, as determined and prescribed, e.g., by aclinician treating patient 1. In the example of FIG. 5, infusionschedule 72 is a time-varying schedule, sometimes referred to as a“flex” schedule, which includes a common infusion pattern 76 that isrepeated daily, such that the infusion pattern 76 on Day 1 is the sameas the infusion pattern for Days 2, 3, 4, and so forth.

In the example of FIG. 6, infusion schedule 74 is a flex scheduleincluding a number of infusion patterns applied over the course of anumber of days. In particular, infusion schedule 74 includes a firstinfusion pattern 78A on Day 1, a second infusion pattern 78B on Day 2, athird infusion pattern 78C on Day 3 (collectively referred to as“infusion pattern 78”), and so forth. Although FIG. 6 shows each dayhaving a different infusion pattern 78, infusion schedule 74 couldinclude repeated patterns, such as a first infusion pattern on Days 1,3, and 5, a second infusion pattern on Days 2 and 4, and a thirdinfusion pattern on Day 7 (not shown).

Therapy program 64 stored on main memory 60 of processor-controlledmemory 36 in the example of FIG. 2 may also include other parametersthat may be used to determine default infusion schedule 70 stored onbackup memory 62, such as parameters specific to a particulartherapeutic agent. For example, therapy program 64 may includeparameters regarding whether the therapeutic agent delivered to patient1 by IMD 12 has higher risks associated with over infusion or underinfusion and the condition being treated by the therapeutic agent.Additionally, therapy program 64 may include parameters specific topatient 1, including, e.g., patient weight, body composition, theinfusion history of patient 1, including dosage history and/orside-effects associated with that dosage history.

The infusion history may be for the current therapeutic agent beingdelivered by IMD 12 to patient 1 or for similar and related therapeuticagents that were previously delivered to patient 1. In the example shownin FIG. 7, therapy program 64 includes the delivery history 80 of thetherapeutic agent to patient 1. In this example, patient 1 wasprescribed the same infusion schedule 74 that is shown in FIG. 6, butwas permitted to set patient-initiated rate changes 82A, 82B and toinfuse a patient-initiated bolus 84. Because delivery history 80 isdifferent than the prescribed infusion schedule 74, default infusionschedule 70 may be determined based on delivery history 80 rather thaninfusion schedule 74, or default infusion schedule 70 may be determinedbased on some combination of the prescribed infusion schedule 74 and theactual delivery history 80, such as an average of the two.

Generally speaking, default infusion schedules employed in the disclosedexamples provide a backup or last-resort infusion schedule that can beused to maintain infusion of at least a minimum therapeutic amount ofthe therapeutic agent to patient 1 until a physician or other clinicianis able to reprogram IMD 12. A “therapeutic amount” generally refers toan amount of the therapeutic agent that has some minimally-acceptabletherapeutic effect in treating the condition for which patient 1 isreceiving the therapeutic agent infusion. In one example, a “therapeuticamount” is the minimum amount that is necessary to prevent withdrawal bypatient 1 due to under infusion of the therapeutic agent.

In another example, a “therapeutic amount” is the minimum amount that isnecessary to achieve a desired therapeutic result in patient 1, such asto achieve pain management for the patient 1 that, even if pain ordiscomfort is not eliminated, is tolerable by the patient, or tosufficiently dampen spasticity such that the patient is able tofunction, even if the spasticity is not completely eliminated. In thisway, in the event of an error condition affecting therapy program 64,default infusion schedule 70 allows IMD 12 to continue at least aminimally-effective delivery of the therapeutic agent to patient 1rather than shutting IMD 12 down or resorting to a non-patient andnon-therapeutic agent specific base rate installed in IMD 12 atfabrication.

Default infusion schedule 70 may be determined based on therapy program64, for example, by being calculated based on a prescribed therapyinfusion schedule, such as infusion schedule 72 or 74 of FIGS. 5 and 6,respectively, patient delivery history 80 of FIG. 7, or some otherfactor, as described in more detail below. In one example, defaultinfusion schedule 70 is a simplified or less sophisticated version ofinfusion schedule 72 or 74 so that the time-varying dependency oftherapeutic agent delivery is minimized or eliminated when thetherapeutic agent is delivered according to the default infusionschedule. For example, the default infusion schedule may be a constantfixed default infusion rate that is calculated based on the dosage rateor rates of therapy program 64. However, in other examples, the defaultinfusion schedule can be other simplified forms of therapy program 64,such as a particular fixed rate or rate schedule for certain timeperiods that correspond to the therapy program, for example separatefixed rates for each day of the week or for specific times of day (e.g.,morning, afternoon, evening, and night).

In another example, more than one default infusion schedule can beprovided to vary depending on the type of error condition encountered byIMD 12. In one example, default infusion schedule 70 may comprise aplurality of default infusion schedules that are created and stored inIMD 12 in order to respond to a variety of error conditions. Forexample, default infusion schedule 70 may comprise a first defaultinfusion schedule that is a fixed default infusion rate that IMD 12 canresort to in the event that the error condition involves a total loss ofthe time point such that IMD 12 processor 34 has completely lost itsability to determine the present time and the ability to determine whereIMD 12 is in infusion schedule 72 or 74.

A second default infusion schedule may provide an intermediate responsefor a situation where processor 34 has lost the present time, but knowswhere IMD 12 was in therapy program 64 at the time the error conditionarose, such that processor 34 has, in essence, a general knowledge ofwhere it is in infusion schedule 72 or 74. In such a case, the seconddefault infusion schedule may provide for daily average dosage ratesstarting from the point the error condition occurred, such as dailyaverage rates 110A for Day 1, 110B for Day 2, 110C for Day 3, and so on(FIG. 6). Finally, a third default infusion schedule may be a directcopy of infusion schedule 72 or 74 of therapy program 64, for the casewhere the error condition is solely a corruption of therapy program 64in memory 36, but wherein processor 34 has not lost the time point orthe position of IMD 12 within therapy program 64. The third defaultinfusion schedule can be used to write over the corrupted infusionschedule 72, 74 so that IMD 12 can continue with the prescribed infusionschedule. In this way, IMD 12 can take the most sophisticated responseto the error condition.

Default infusion schedule 70 may be determined by any processor, orsimilar device, capable of calculating default infusion schedule 70based on therapy program 64 and any other information in the mannerdescribed above. In one example, processor 26 in external programmer 20determines default infusion schedule 70. In this example, therapyprogram 64 may be stored on memory of external programmer 20 andemployed by processor 26 to determine default infusion schedule 70. Oncedefault infusion schedule 70 is determined, the default infusionschedule and therapy program 64 may be transmitted to IMD 12 byprogrammer 20 and stored in memory, e.g., backup memory 62 and mainmemory 60, respectively. In another example, at least one of processor34 or hardware controller 44 of IMD 12 may determine default infusionschedule 70 based on therapy program 64 (and any other relevantinformation) stored on main memory 60 or, in some examples prior to thecompletion of programming IMD 12, a memory of external programmer 20.

In another example, rather than storing different default infusionschedules to respond to different error conditions, IMD 12 may beconfigured so that the default infusion schedule 70 is determined upondetection of the error condition, such that the type of default infusionschedule that is used can be appropriate for the type of errorcondition. For example, if the error condition involves a complete lossof time point wherein IMD 12 does not know the present time and is alsounable to accurately measure the passage of time going forward, thenprocessor 34 may calculate a fixed default infusion rate to act asdefault infusion schedule 70 until IMD 12 can be reprogrammed. If,however, the error condition only involves a partial time loss wherebyIMD 12 knows the day when the error condition occurred, but not the timeof the day, and IMD 12 is able to reliably measure time going forward,then processor 34 may determine a default infusion schedule, which maybe a fixed rate, for the next 24 hours. After the passage of thisinitial 24 hours, processor 34 may again calculate a new defaultinfusion schedule for the following 24 hours. This process can berepeated for each cycle of 24 hours until IMD 12 is reprogrammed. Timedurations other than 24 hours may be used, such as an hourly time cycle,a four-hour time cycle, a six-hour time cycle, a twelve-hour time cycle,and so on.

As described above with respect to FIG. 2, in one example, defaultinfusion schedule 70 is stored in backup memory 62 ofprocessor-controlled memory 36 while therapy program 64 is stored inmain memory 60. Main memory 60 and backup memory 62 can be any memorywithin IMD 12, such as a processor-controlled memory 36, including ROM50, RAM 52, or flash memory 54, or a hardware-controlled memory 56 suchas hardware registers 58 associated with hardware controller 44. In oneexample, main memory 60 is a portion of a processor-controlled memory36, such as a portion of RAM 52 as shown in FIG. 2, and backup memory 62is a different portion of processor-controlled memory 36, such as aportion of flash memory 54 as shown in FIG. 2. Backup memory 62containing default infusion schedule 70 may be a portion of the sametype of memory as main memory 60 containing therapy program 64. In theexample of FIG. 3, main memory 60 and backup memory 62A are both part ofRAM 52. Alternatively, backup memory 62 may be a portion of a differenttype of memory as main memory 60. In on example shown in FIG. 3, thebackup memory 62B is a portion of flash memory 54 ofprocessor-controlled memory 36, while main memory 60 is a portion of RAM52. In another example shown in FIG. 4, backup memory 62B is a part ofhardware registers 58 of hardware-controlled memory 56, while mainmemory 60 is a portion of RAM 50 of processor-controlled memory 36.

Default infusion schedule 70 may also be redundantly stored in more thanone backup memory 62 by storing a first copy of default infusionschedule 70A in one portion of memory and redundantly storing a secondcopy of default infusion schedule 70B in the same type of memory or adifferent type of memory as the first copy. In one example, shown inFIG. 3, a first copy of default infusion schedule 70A is stored in afirst backup memory 62A that is a first portion of processor-controlledmemory 36, e.g., a portion of RAM 52, while a second redundant copy ofdefault infusion schedule 70B is stored in a second backup memory 62Bthat is another portion of processor-controlled memory 36, e.g., aportion of flash memory 54, or another portion of RAM 52 (not shown). Inanother example, shown in FIG. 4, a first copy of default infusionschedule 70A is stored in a first backup memory 62A that is a portion ofprocessor-controlled memory 36, e.g., a portion of flash memory 54,while a second copy of default infusion schedule 70B is stored in asecond backup memory 62B that is a portion of a hardware-controlledmemory 56, e.g., a portion of hardware registers 58.

Redundant storage of default infusion schedule 70 provides an additionalbackup in the event the first copy of default infusion schedule 70A isfound, e.g., by processor 34, to be corrupted or not valid for someother reason, in which case the processor may use the second copy 70B toupdate the first copy 70A and/or use the second copy 70B as theoperating infusion schedule. In another redundant storage example,default infusion schedule 70 is stored in such a way that a copy ofdefault infusion schedule 70 is accessible to each of processor 34 andhardware controller 44. This example may be useful to allow IMD 12 torespond to error conditions in which processor 34 is functioningproperly but therapy program 64 should not be used, and to respond toerror conditions in which processor 34 or the IMD software is notfunctioning properly. In this example, default infusion schedule 70 maybe stored in a backup memory 62 that is accessible to both processor 34and hardware controller 44, or default infusion schedule 70 may bestored in a first backup memory 62A that is a portion of aprocessor-controlled memory 36, such as flash memory 54 shown in FIG. 4,for access by processor 34, and in second backup memory 62B that is aportion of a hardware-controlled memory 56, such as in hardwareregisters 58 as shown in FIG. 4, for access by hardware controller 44.

FIGS. 8 and 10-13 are flow charts illustrating several example methodsrelated to the determination and use of default infusion schedules. FIG.8 is directed to a general example of determining a default infusionschedule based on a prescribed therapy program and using the defaultinfusion schedule in the event an error condition is detected. FIGS.10-13 are directed to several example methods of storing one or moredefault infusion schedules, e.g., on memory of an IMD, and of detectingvarious error conditions that necessitate use of the default infusionschedules. For illustrative purposes, the various functions included inthe example methods illustrated in FIGS. 8 and 10-13 are described belowas executed by one of processor 34 or hardware controller 44 of IMD 12,or processor 26 of programmer 20. However, these functions may all beexecuted by a single processor, or different combinations of thesefunctions may be executed by different combinations of processor 34 andhardware controller 44 of IMD 12, and processor 26 of programmer 20, aswell as processors of other external devices.

The example method of FIG. 8 includes determining therapy program 64(90); determining a default infusion schedule based on a therapy program64 specific to patient 1 (92); delivering default infusion schedule 70and therapy program 64 to IMD 12 (94); storing default infusion schedule70 on a backup memory 62 of IMD 12 (96); determining if an errorcondition is present in IMD 12 such that IMD 12 cannot reliably delivera therapeutic agent based on the therapy program 64 (98); if the errorcondition is present, delivering the therapeutic agent according to thedefault infusion schedule (100); and if the error condition is notpresent, continuing with the prescribed therapy program 64 (102). Themethod of FIG. 8 may also include initiating an alarm (103) indicatingthat the error condition was detected and that default infusion schedule70 is being used.

In one example, determining the therapy program (90) and determining thedefault infusion schedule (92) may be performed by a processor of anexternal device, e.g., processor 26 of external programmer 20. In suchexamples, therapy program 64 and/or default infusion schedule 70 aredelivered to IMD 12 (94), e.g., wirelessly via telemetry module 38. Asexplained above, default infusion schedule may be stored on backupmemory 62 of IMD 12 (96). Additionally, therapy program 64 may be storedin main memory 60 of IMD 12. In examples in which determining therapyprogram 64 (90) is performed by external programmer 20, or anotherexternal device, the determination may be performed either by directprogramming by a clinician or by an algorithm or program thatautomatically determines therapy program 64 based on parametersassociated with the therapeutic agent, e.g., whether the therapeuticagent has higher risks associated with over infusion or under infusionand the condition being treated by the therapeutic agent, or parametersspecific to patient 1, e.g., patient weight, body composition, and theinfusion history of patient 1. In one example, a clinician enterstherapy parameters to define therapy program 64 including, e.g., one ormore therapeutic agent doses, dose rates, and a therapy infusionschedule for delivering the doses at particular times.

In another example, determining default infusion schedule 70 (92) may beperformed by processor 34 or hardware controller 44 onboard IMD 12 basedon therapy program 64 stored within main memory 60 of IMD 12. Forexample, as described in more detail below, processor 34 or hardwarecontroller 44 may perform calculations or run an algorithm necessary todetermine default infusion schedule 70. Additionally, in one example,processor 34 or hardware controller 44 may periodically verify thatdefault infusion schedule 70 stored on backup memory 62 is uncorruptedand valid. If default infusion schedule 70 is found to be corrupted orinvalid for some other reason, processor 34 or hardware controller 44may re-determine the default infusion schedule based on therapy program64 and replace the corrupted or invalid default infusion schedule withthe re-determined default infusion schedule.

Determining default infusion schedule 70 based on therapy program 64(92) can be accomplished according to a variety of specific methods. Inone example, default infusion schedule 70 is determined using analgorithm that performs calculations based on therapy program 64 andthat is executed by one or more of processor 26 of external programmer20 or processor 34 or hardware controller 44 within IMD 12. The specificmethod employed to determine default infusion schedule 70 (92) maydepend on the characteristics of therapy program 64. For example, iftherapy program 64 comprises an infusion schedule that includes onefixed infusion rate, then determining default infusion schedule 70 (92)may only include copying the fixed therapy infusion rate as a fixeddefault infusion rate for default infusion schedule 70. However, iftherapy program 64 includes a time-varying infusion schedule, such asinfusion schedules 72 and 74 of FIGS. 5 and 6, respectively, thenseveral methods of determining default infusion schedule 70 may be used.

In one example in which therapy program 64 includes a repeating daily“flex” infusion pattern, such as infusion pattern 76 of the exampleshown in FIG. 5, the default infusion schedule determination algorithmmay be configured to determine the total daily dose for flex infusionpattern 76 and convert the total daily does to a fixed default infusionrate that achieves the total daily dose over a twenty-four hour period.In other words, the algorithm determines the average daily dosage rate,represented by line 104 in FIG. 5, and sets default infusion schedule 70as a fixed default infusion rate that is equal to the average dailydosage rate 104. For example, in infusion schedule 72 shown in FIG. 5,each day comprises the same infusion pattern 76, which may result in atotal infusion of 550 micrograms (mcg) of a therapeutic agent, or about22.9 mcg of the therapeutic agent per hour, as represented by line 104in FIG. 5. In this example, the default infusion schedule determinationalgorithm may determine that default infusion schedule 70 is to be afixed default infusion rate of 22.9 mcg/hour, representing the averageinfusion rate for infusion schedule 72. In another example, defaultinfusion schedule 70 may be set as a fixed default infusion rate that isequal to the minimum infusion rate that is delivered in accordance withinfusion schedule 72, represented by line 106 in FIG. 5, or that isequal to a maximum infusion rate that is delivered in accordance withinfusion schedule 72, represented by line 108 in FIG. 5.

In another example, therapy program 64 includes an infusion schedulewith a number of different infusion patterns for different time periods,such as the example infusion schedule 74 shown in FIG. 6, which includesfirst infusion pattern 78A for Day 1, second infusion pattern 78B forDay 2, third infusion pattern 78C for Day 3, fourth infusion pattern 78Dfor Day 4, and so forth (collectively referred to as “infusion patterns78”). In such an example, determining default infusion schedule 70 (90)may include configuring an algorithm to determine default infusionschedule 70 based on any number of calculations based on one or more ofthe different infusion patterns 78. For example, each day's infusionpattern 78 may correspond to a daily average infusion rate, such asaverage infusion rate 110A for Day 1 infusion pattern 78A, averageinfusion rate 110B for Day 2 infusion pattern 78B, and so on(collectively referred to herein as “daily average infusion rate(s)110”).

Default infusion schedule 70 may be set as a fixed default infusion ratebased on one of the average infusion rates 110, such as the minimumdaily average infusion rate 110, which, in the example of FIG. 6 isdaily average infusion rate 110C for Day 3 infusion pattern 78C.Additionally, default infusion schedule 70 may be set as the most common(or modal) daily average infusion rate 110, wherein daily averageinfusion rates may be rounded to a particular number of significantfigures so that rates that are close to one another can be considered tobe equal for purposes of the modal determination. In another example,default infusion schedule 70 may be set as the maximum average infusionrate 110, e.g., daily average infusion rate 110D for Day 4 infusionpattern 78D in FIG. 6, a median daily average infusion rate 110, e.g.,daily average infusion rate 110B for Day 2 infusion pattern 78B, or theaverage of the entire infusion schedule 74, represented by line 112 inFIG. 6.

Referring to one particular example of infusion schedule 74 of FIG. 6,Day 1 infusion pattern 78A may total 550 mcg for all of Day 1,corresponding to a daily average infusion rate 110A of about 22.9mcg/hour. Day 2 infusion pattern 78B may total 425 mcg, corresponding toa daily average infusion rate 110B of about 17.7 mcg/hour. Day 3infusion pattern 78C may total 100 mcg, corresponding to a daily averageinfusion rate 110C of about 4.2 mcg/hour. Day 4 infusion pattern 78D maytotal 650 mcg, corresponding to a daily average infusion rate 110D ofabout 27.1 mcg/hour. Day 5 infusion pattern 78E may total 300 mcg,corresponding to a daily average infusion rate 110E of 12.5 mcg/hour.Day 6 infusion pattern 78F may total 450 mcg, corresponding to a dailyaverage infusion rate 110F of about 18.8 mcg/hour. Day 7 infusionpattern 78G may total 325 mcg, corresponding to a daily average infusionrate 110C of about 13.5 mcg/hour. These example values for infusionpatterns 78 and daily average infusion rates 110 correspond to a totalinfusion of the therapeutic agent of 2,800 mcg over the entire infusionschedule 74, which averages out to about 16.7 mcg per hour over theentire seven-day (168 hour) period of infusion schedule 74.

Assuming the foregoing values for infusion schedule 74, a defaultinfusion schedule determination algorithm may set default infusionschedule 70 as a fixed default infusion rate equal to the minimum dailyaverage infusion rate 110, e.g., the 4.2 mcg/hour rate 110C from Day 3.The default infusion schedule determination algorithm may also setdefault infusion schedule 70 as a fixed default infusion rate equal tothe median daily average infusion rate 110, e.g., the 17.7 mcg/hour rate110B from Day 2. Default infusion schedule 70 may also be set as a fixeddefault infusion rate equal to the average of the daily average infusionrates 110, e.g., 16.7 mcg per hour, represented by line 112 in FIG. 6,or the maximum daily average infusion rate 110, e.g., the 27.1 mcg/hourrate 110D from Day 4. Although the example method described in relationto FIGS. 5 and 6 describe determining default infusion schedule 70 basedon daily infusion patterns 76 and 78, respectively, the infusionpatterns of other time periods can be used, such as hourly, every twelvehours, daily, or weekly.

In another example, instead of setting default infusion schedule 70 toone fixed infusion rate over a number of days, the default infusionschedule may include a time-varying schedule such that it approximates atime-varying therapy program 64, while still simplifying the originalversion of the therapy program to facilitate infusion of a therapeuticamount of the therapeutic agent to patient 1 in the event of an errorcondition. In one example, an algorithm determines default infusionschedule 70 by determining an average infusion rate for each of aplurality of time periods of infusion schedule 74 and setting defaultinfusion schedule 70 as a series of the time periods with each timeperiod having its own fixed infusion rate equal to the correspondingaverage infusion rate for that time period. For example, with referenceto the example infusion schedule 74 shown in FIG. 6, default infusionschedule 70 may comprise a fixed infusion rate on Day 1 that is set tobe equal to the daily average infusion rate 110A for Day 1, a fixedinfusion rate on Day 2 set to the daily average infusion rate 110B, afixed infusion rate on Day 3 set to the daily average infusion rate110C, a fixed infusion rate on Day 4 set to the daily average infusionrate 110D, a fixed infusion rate on Day 5 set to the daily averageinfusion rate 110E, a fixed infusion rate on Day 6 set to the dailyaverage infusion rate 110F, and a fixed infusion rate on Day 7 set tothe daily average infusion rate 110F. The resulting example defaultinfusion schedule 70 determined by this method is shown in FIG. 9.

In another example, a plurality of flex infusion schedules may beprovided for patient 1, for example infusion schedule 72 of FIG. 5 couldbe provided for the first week of therapy and infusion schedule 74 ofFIG. 6 could be provided for the second week of therapy. Alternatively,several different flex infusion schedules could be provided for infusionof the therapeutic agent to patient 1. In the case where a plurality offlex infusion schedules are provided, determining default infusionschedule 70 (92) may include determining a default infusion schedulebased on any of the methods described above for each of the flexinfusion schedules provided, and then selecting the default infusionschedule having the lowest average infusion rate, a median averageinfusion rate, or a highest average infusion rate. Selection of adefault infusion schedule to use as the default infusion schedule 70 tobe saved in backup memory 62 may depend on patient-specific parameters,therapeutic agent-specific parameters, or parameters specific to fluidinfusion device 12, such as the parameters described above.

In another example of the method of FIG. 8, determining default infusionschedule 70 (92) may include determining more than one default infusionschedule. For example, a default infusion schedule determinationalgorithm may be configured to determine a first default infusionschedule including a time-varying schedule, such as the default infusionschedule 70 described above with respect to FIG. 9, and a second defaultinfusion schedule 70 including a fixed default infusion rate, such as afixed rate set to one of the daily average infusion rates 110 from FIG.6. In this example, IMD 12 may select the first or the second defaultinfusion schedule based on the type of error condition that is detected.Generally speaking, a first error condition may result in the use of thefirst default infusion schedule while a second error condition mayresult in the use of the second default infusion schedule.

In one example, the first default infusion schedule, e.g., thetime-varying default infusion schedule, may be used if the errorcondition does not involves a complete loss of the time point by IMD 12such that IMD 12 still has at least an approximate sense of the currenttime, e.g., processor 34 knows when the first error condition occurredand approximately how much time has elapsed since the error conditionoccurred, within a predetermined period of time. In this situation, IMD12 is able to keep an accurate account of the passage of time goingforward, such that the use of a time-varying default infusion scheduleis appropriate. The second default infusion schedule, e.g., a fixeddefault infusion rate, may be used if the error condition involves acomplete loss of the time point by IMD 12 such that the device does notknow where in time it is in the infusion schedule currently beingexecuted.

In some examples, rate-selector tables, e.g., stored onprocessor-controlled memory 36 of IMD 12, may also be provided todetermine default infusion schedule 70 in the event of an errorcondition in the device. The rate-selector tables may comprise one ormore continuous rate infusion tables or bolus tables. In one example,the determination of default infusion schedule 70 (90) may be based onone or more values from one or more rate-selector tables. For example,when IMD 12 is programmed, two or more default infusion schedules may bedetermined, such as by processor 26 of external programmer 20 or byprocessor 34 of IMD 12, and stored in memory, such asprocessor-controlled memory 36. The two or more default infusionschedules are referred to collectively herein as a “rate-selectortable.” Each of the two or more default infusion schedules may bedetermined by any of the methods described in this disclosure, such asby selecting the minimum infusion rate across a prescribed infusionschedule, an average infusion rate across the infusion schedule, or oneor more average rates of portion of the infusion schedule. Processor 34,hardware controller 44, or firmware within IMD 12 may be configured toselect one of the two or more default infusion schedules from therate-selector table. Which of the default infusion schedules that areselected may depend on the type of error condition that is detected andthe stage of infusion when the error condition occurred. In one example,each default infusion schedule in the rate-selector table is fixedinfusion rate and the default infusion schedule 70 is a fixed defaultinfusion rate that is set at a minimum infusion rate from therate-selector tables, a maximum infusion rate from the rate-selectortables, a median infusion rate from the rate-selector tables, a modalinfusion rate from the rate-selector tables, or an average infusion ratefrom rate-selector tables.

In addition to therapy program 64, default infusion schedule 70 may, insome examples, be based on an actual delivery history of the therapeuticagent to patient 1, such as the example delivery history 80 (FIG. 7)that shows the delivery of the therapeutic agent to patient 1 over theprevious seven days. As described above, example delivery history 80includes patient-initiated rate changes 82A, 82B and a patient-initiatedbolus 84 that patient 1 selects to delivery on top of prescribedinfusion schedule 74 from FIG. 6. Delivery history 80 may be used todetermine default infusion schedule 70 in much the same way infusionschedule 74 may be used to determine default infusion schedule 70, asdescribed above with respect to FIG. 6.

For example, the average infusion rate 114 for each day of deliveryhistory 80 can be calculated, such as average infusion rate 114A for Day1, average infusion rate 114B for Day 2, and so on (collectivelyreferred to herein as “daily average infusion rate(s) 114”). As withinfusion schedule 74 of FIG. 6, default infusion schedule 70 may basedon delivery history 80 by being set as a fixed default infusion ratebased on one of the daily average infusion rates 114, such as theminimum daily average infusion rate 114C, the maximum daily averageinfusion rate 114D, the most common (or modal) daily average infusionrate 114 (none in FIG. 7), or a median daily average infusion rate 114B.

Default infusion schedule 70 may also be set as a fixed default infusionrate based on the average of the entire delivery history 80, representedby line 116 in FIG. 7, a minimum infusion rate for the entire deliveryhistory 80, represented by line 118, or a maximum infusion rate for theentire delivery history 80, represented by line 119 in FIG. 7. Themaximum infusion rate for the entire delivery history may include anypatient-initiated rate change 82A, 82B or bolus 84 (not shown in FIG.7), or may be selected such that patient-initiated infusion are ignoredas is the case in the example of FIG. 7. Although the example methoddescribed in relation to FIG. 7 describes determining default infusionschedule 70 based on calculations of each day of delivery history 80,such as by determining a daily average infusion rate 114, the infusionpatterns of other time periods can be used, such as hourly, every twelvehours, daily, or weekly.

In another example, an aggregate of the programmed infusion schedule,such as infusion schedule 72 or 74, and the delivery history 80, may beused to determine default infusion schedule 70. For example, if itdesired to use a minimum daily average infusion rate as the defaultinfusion rate, the average of minimum daily average infusion rate 110Cfrom Day 3 of infusion schedule 74 (FIG. 6) and minimum daily averageinfusion rate 114C from Day 3 of infusion history 80 may be used as thefixed default infusion rate. The aggregate may be calculated to givemore weight to either infusion schedule 74 or to delivery history 80 sothat one or the other may have more influence on the final aggregatevalue or values used for default infusion schedule 70.

In another method of determining default infusion schedule 70 (92), auser determines one or more default infusion schedules for use by IMD 12in the event an error condition is detected. For example, the user, suchas a physician or other clinician, may determine and set the defaultinfusion schedule, such as a fixed default infusion rate, based oncharacteristics of the patient, such as the therapy program and therapyschedule that has been prescribed for the patient, the patient's historywith the therapeutic agent being delivered, and any other factors theuser may feel is pertinent to the determination of the default infusionschedule to be followed in the event of an error condition. In anotherexample, the processor, such as processor 26 of external programmer 20or IMD processor 34, may determine a plurality of default infusionschedules, such as a number of fixed default infusion rates determinedby any of the methods described above, whereupon a user, such as aclinician or patient 1, e.g., using external programmer 20, may selectone of the fixed default infusion schedules for use by IMD 12 in theevent of an error condition. In another example, the user may select thealgorithm that will be used to determine the default infusion schedule,such as from a menu of a number of algorithms provided to the user,e.g., via programmer 20.

In another example, determining default infusion schedule 70 (92) mayinclude determining a base infusion schedule and determining a finaldefault infusion schedule that will be stored on backup memory 62 and beused by IMD 12 by adding, subtracting, multiplying, or dividing a ratefactor to the base infusion schedule. Generally speaking, the baseinfusion schedule may be determined by any of the methods describedabove for determining default infusion schedule 70. The rate factor maybe determined based on parameters that are specific to the therapeuticagent, such as side effects that are associated with over infusion orunder infusion of the therapeutic agent. For example, if the therapeuticagent is a drug with a higher likelihood of overdose, then a particularrate factor may be subtracted from the base infusion schedule. Examplesof this type of therapeutic agent include morphine. In another example,if the therapeutic agent is a drug with adverse effects associated withunder infusion, such as severe withdrawal symptoms, than a particularrate factor may be added to the base infusion schedule, for example byincreasing the fixed default infusion rate that is determined by analgorithm by a set amount. Examples of this type of therapeutic agentinclude drugs such as baclofen. The rate factor may also be determinedbased on parameters that are specific to patient 1, such as conditionbeing treated, patient weight, and patient history with the therapeuticagent or other therapeutic agents. The rate factor may also bedetermined based on parameters that are specific to IMD 12.

In some therapeutic examples, patient 1 may be switched from treatmentwith a first fluid having a corresponding first therapy program totreatment with a second fluid having a corresponding second therapyprogram, also referred to as a bridge condition. The second fluid may bea different therapeutic agent altogether than the first fluid, or thesecond fluid may be of the same therapeutic agent, but with a differentconcentration of the therapeutic agent. In either case, e.g., changingthe therapeutic agent or changing the concentration of the sametherapeutic agent, the first fluid remaining in reservoir 32 is removed,such as by inserting a syringe needle into reservoir 32 to draw thefluid out, but there still remains some fluid in internal channels 46and catheter 14. The second fluid, e.g., the new therapeutic agent orthe fluid having a new concentration of therapeutic agent, is theninjected into reservoir 32. A bridge condition may occur, for example,while the second fluid is being removed from reservoir 32 while at leastsome of the first therapeutic agent is still in the flow path downstreamof medical pump 42, such as within internal channels 46 and catheter 14.During the bridge condition, both the first and second fluids may bepresent in catheter 14, and thus, for a period of time, may both beinfused into patient 1.

The bridge condition may be considered to continue until the first fluidhas been emptied from the downstream flow path. In one example, thefirst fluid is assumed to be emptied from the downstream flow path whena predetermined volume of the second fluid has been pumped by medicalpump 42, such as a volume equal to the volume of the downstream flowpath or some multiple thereof, such as between about 1 and about 3 timesthe volume of the downstream flow path, for example about 2 times thedownstream flow path. In another example, the first fluid is consideredto be emptied from the downstream flow path after a predetermined periodof time has elapsed, wherein the predetermined time is the time it isexpected that it will take for the first fluid to be pumped out of thedownstream flow path. The predetermined period of time can be determinedbased on an expected average infusion rate during the bridge condition.

In one example including a bridge condition, determining defaultinfusion schedule 70 (92) may include determining a first defaultinfusion schedule for the first fluid, determining a second defaultinfusion schedule for the second fluid, and selecting either the firstdefault infusion schedule or the second default infusion schedule to bethe default infusion schedule during the bridge condition. For example,the default infusion schedule for each fluid may be stored in memory,such as in a rate-selector table in processor-controlled memory 36,wherein processor 34, hardware controller 44, or firmware within IMD 12may be configured to select one of the default infusion schedules fromthe rate-selector table to use based on wherein IMD 12 believes it is inthe bridge condition. After the first fluid is withdrawn from reservoir32 and the second fluid is injected into reservoir 32, the secondtherapy program and the second default infusion schedule correspondingto the second fluid may be sent to IMD 12, such as via telemetry module38. In one example, the volume of the first fluid that remains in thedownstream flow path is determined based on the known length of interiorchannels 46 and catheter 14 and processor 34 or hardware controller 44keeps track of the amount of the second fluid being delivered by medicalpump 42 to determine if the volume of the first fluid has beendelivered. If an error condition occurs before the volume of the firstfluid in the downstream flow path has been delivered, then processor 34or hardware controller 44 will use the first default infusion scheduleof the first fluid until the remainder of the volume of the first fluidin downstream flow path is delivered. At that point, processor 34 orhardware controller 44 will switch to using the second default infusionschedule.

In another example, when the second fluid is injected into reservoir 32,a time stamp is sent to IMD 12, such as via telemetry module 38, forstorage in memory, such as processor-controlled memory 36 orhardware-controlled memory 56. The time stamp indicates the amount oftime that is expected to be required to pump the first fluid out of thedownstream flow path. Upon detection of an error condition that causesIMD 12 to transition to using a default infusion schedule during thebridge condition, IMD 12 uses the time stamp to determine which of thefirst default infusion schedule (for the first fluid) or the seconddefault infusion schedule (for the second fluid) will be used at aparticular point in time. The first default infusion schedule is used todirect infusion by medical pump 42 up until the time stamp. After thetime stamp is reached, the second default infusion schedule is used.

In another example, determining default infusion schedule 70 (92) mayinclude determining a bridge default infusion schedule that is based onsome combination of the first default infusion schedule for the firstfluid and the second default infusion schedule for the second fluid. Thebridge default infusion schedule may be selected to be the moreconservative of the first default infusion schedule and the seconddefault infusion schedule. The “more conservative” of the first and thesecond default infusion schedules may be a function of variousparameters specific to the first and second fluids, such as side effectsthat are associated with over infusion or under infusion of each fluid.

Parameters that may be used to determine the “more conservative” of thefirst and second default infusion schedules may be specific to patient1, such as condition being treated, patient weight, and patient historywith each fluid. For example, if both the first fluid and the secondfluid involve adverse side effects associated with under infusion withrelatively little risk of an overdose due to over infusion, then the oneof the first or the second default infusion schedule having the largeroverall output, e.g., the amount of therapeutic agent that would beinfused into patient 1 over the entirety of the default infusionschedule, may be selected to be the bridge default infusion rate toavoid patient 1 experiencing side effects of under infusion of eitherthe first or second fluid. In another example in which one or both ofthe first fluid and the second fluid have risks associated with overinfusion, then the one of the first or the second default infusionschedule having the lower overall output may be selected as the bridgedefault infusion schedule to avoid the side effects associated with overinfusion.

In another example of determining a bridge default infusion schedule aspart of determining default infusion schedule 70 (92) in the method ofFIG. 8, the bridge default infusion schedule may be calculated based onboth the first default infusion schedule and the second default infusionschedule, such as by averaging the two schedules or by giving weight toagent-specific factors such as the side effects associated with overinfusion and under infusion of the first and second therapeutic agents.For example, if the first default infusion schedule for the firsttherapeutic agent is a fixed default infusion rate of 15 mcg/hour andthe second default infusion schedule of the second therapeutic agent isa fixed default infusion rate of 20 mcg/hour, the default infusion rateduring the bridge condition may be set at 15 mcg/hour, e.g., the lowerof the two rates, at 20 mcg/hour, e.g., the higher of the two rates, at17.5 mcg/hour, e.g., the average of the two rates, or somewhere elsebetween 15 and 20 mcg/hour depending on the particular therapeuticagents involved.

Referring again to the example method of FIG. 8, in addition todetermining default infusion schedule 70 (92), the method includesstoring the default infusion schedule 70 on backup memory 62 of IMD 12(96). Storing the default infusion schedule 70, such as on backup memory62 (96) may include any one of several storage configurations. In theexample shown in FIG. 2, storing default infusion schedule 70 (96)includes storing the default infusion schedule 70 in backup memory 62included in processor-controlled memory 36. In other examples, storingdefault infusion schedule 70 (96) in the method of FIG. 8 may includeany of the various storage configurations illustrated in and describedabove with reference to FIGS. 3 and 4 including storage on backup memory62A of RAM 52 or backup memory 62B of flash memory 54 ofprocessor-controlled memory 36 in the example of FIG. 3, as well asstorage on backup memory 62B of hardware registers 58 ofhardware-controlled memory 56 in the example of FIG. 4.

In addition to storing default infusion schedule 70 on backup memory 62of IMD 12 (96), the method of FIG. 8 includes determining if an errorcondition is present in IMD 12 (98). Determining if an error conditionis present (98) may, generally speaking, be performed by processor 34,hardware controller 44, or both. As described above, in some examples,processor 34 may be configured to recognize error conditions such ascorruption of therapy program 64, other memory corruption that affectsdelivery of therapeutic agent, loss of time point by processor 34, pumpsoftware errors, pump reset, and the like, and hardware controller 44may be configured to recognize error conditions in which processor 34itself or pump software are malfunctioning.

In the event that an error condition is detected, e.g., by processor 34of IMD 12, the method of FIG. 8 includes delivering the therapeuticagent to patient 1 according to default infusion schedule 70 (100) inorder to maintain infusion of at least a minimum therapeutic amount ofthe therapeutic agent to patient 1 until a physician or other clinicianis able to reprogram IMD 12. Delivery of the therapeutic agent topatient 1 according to default infusion schedule 70 (100) may bedirected by processor 34 or hardware controller 44. In one example,wherein the error condition is such that processor 34 is still able tocontrol infusion by medical pump 42, then processor 34 may accessdefault infusion schedule 70 from backup memory 62 and may directhardware controller 44 to deliver the therapeutic agent according todefault infusion schedule 70. In another example, wherein the errorcondition is one wherein processor 34 or pump software ismalfunctioning, hardware controller 44 may access default infusionschedule 70 from backup memory 62 and control medical pump 42accordingly.

In yet another example, hardware controller 44 is responsible fordirecting delivery of the therapeutic agent according to defaultinfusion schedule 70 regardless of which type of error condition isdetected. If hardware controller 44 detects the error condition, itaccesses default infusion schedule 70 from backup memory 62 and controlmedical pump 42 accordingly. If processor 34 detects the errorcondition, it communicates the detection of the error condition tohardware controller 44, which then directs delivery of the therapeuticagent according to default infusion schedule 70. One example of a methodof communicating the error condition from processor 34 to hardwarecontroller 44 includes communication through a specific protocol, suchas writing to hardware-controlled memory 56 or a more robust messagingscheme between processor 34 and hardware controller 44. Another examplemay be stopping communication or ceasing an exchange of signal, e.g., ifthere is a watchdog or beacon or message exchange between processor 34and hardware controller 44 that is occurring on a regular basis which isthen stopped by processor 34. In yet another example, a logtype-supplementary communication is provided by which processor 34provides hardware controller 44 with information regarding what type oferror condition was detected so that hardware controller 44 may use adefault infusion schedule that is a proper response to the errorcondition detected.

FIG. 10 is a flowchart illustrating a first example method of storing adefault infusion schedule in a backup memory of an IMD and detecting anerror condition within an IMD. The example method of FIG. 10 may beexecuted in whole or in part by one or more of processor 34 or hardwarecontroller 44 of IMD 12, processor 26 of programmer 20, or a processorof another device. The example method of FIG. 10 includes storingdefault infusion schedule 70 in processor-controlled memory 36 of IMD 12(120), and determining if an error condition exists in IMD 12 (122),such as by detecting that therapy program 64 is corrupt in main memory60 or determining that processor 34 has lost time point. If no errorcondition exists, IMD 12 continues to use the prescribed therapy program64 to deliver therapy to patient 1 (123).

If an error condition does exist, default infusion schedule 70 isverified as uncorrupted and valid in backup memory 62 (124). If defaultinfusion schedule 70 is found to be uncorrupted and valid, IMD 12employs default infusion schedule 70 to direct delivery of thetherapeutic agent to patient 1 (126). The method may also optionallyinclude triggering an alarm (128) when an error condition is detected.For example, IMD 12 may include an audible or vibratory alarm device 49(FIG. 2) that immediately alerts patient 1 that an error condition wasdetected and that default infusion schedule 70 is being used. An examplealarm device 49 may include a sound system, such as a piezoelectricdevice, that is activated by processor 34 or hardware controller 44 upondetection of the error condition and use of default infusion schedule70. Alarming may also include displaying an alarm message on externalprogrammer 20 or another device in communication with IMD 12 orprogrammer 20 to alert patient 1 or another user, such as a clinician,of the existence of the error condition or the use of default infusionschedule 70. If default infusion schedule 70 is found to be corrupt orinvalid for some other reason, IMD 12 ceases delivery of the therapeuticagent (130) and initiates an alarm (132), such as by processor 34 orhardware controller 44 instructing medical pump 42 to stop delivery ofthe therapeutic agent and delivering an alarm message via telemetrymodule 38 to external programmer 20.

Alarms associated with the example method of FIG. 10, as well as anyother methods described in this disclosure, may be triggered byprocessor 34 or hardware controller 44 of IMD 12 or a processor ofanother device, e.g., processor 26 of programmer 20, and may generallyinclude audible, tactile, and/or visual alerts. For example, an errorcondition detection alarm may include audible alerts issued byprogrammer 20 or another external device associated with therapy system10. In another example, the triggered alarm includes IMD 12 vibratingwithin the body of patient 1, thereby providing a tactile alert. Inanother example, processor 34 or hardware controller 44 may beconfigured to prompt external programmer 20, or another deviceincorporated in or communicatively connected to IMD 12, to provide analert message to patient 1 or a clinician, such as by providing an audioor visual alert. In one example, IMD 12 or programmer 20 may beconfigured to be in communication with a monitoring or relaying device,such as a home monitor within the patient's home, wherein the monitoringor relaying device is in communication with a monitoring station, suchas within a clinic or hospital that is monitored by a clinician, througha network, such as the internet, a LAN, a WAN, a PSTN, or a cellulartelephone network. Other alert messages may include text or graphicalmessages delivered to patient 1 and/or a clinician via text message ore-mail from programmer 20 or another electronic device communicativelyconnected to IMD 12 and/or programmer 20.

Another example method of storing default infusion schedule 70 anddetecting error conditions within IMD 12 is illustrated in the flowchart of FIG. 11. The method of FIG. 11 includes storing a first copy ofthe default infusion schedule 70 in a first portion of backup memory 62that is a portion of processor-controlled memory 36 (134) andredundantly storing a second copy of default infusion schedule 70 in asecond portion of backup memory 62 that is a portion ofprocessor-controlled memory 36 (136). Storing the first copy of defaultinfusion schedule 70 (134) may include, e.g., storing a first copy ofdefault infusion schedule 70A in backup memory portion 62A of RAM 52, asillustrated in the example of FIG. 3. Redundantly storing a second copyof default infusion schedule 70 (136) may include, e.g., storing asecond copy of default infusion schedule 70B in backup memory portion62B of flash memory 54, as also illustrated in FIG. 3. Additional copiesof the default infusion schedule may be stored in other areas of mainmemory 60 or backup memory 64, such as third, fourth, and fifth copiesof the default infusion schedule in third, fourth, and fifth portions ofbackup memory.

After storing a first copy (134) and redundantly storing a second copy(136), the example method of FIG. 11 includes determining if an errorcondition is present in IMD 12 (138). If no error condition is present,IMD 12 continues to use prescribed therapy program 64 (139). If an errorcondition is present, the example method of FIG. 11 includes initiatingan alarm indicating that an error condition is present (150).

IMD may also be configured so that whenever default infusion schedule 70is updated or changed, all locations of backup memory 62 where copies ofdefault infusion schedule 70 are stored are synchronized and updatedsubstantially simultaneously. The synchronized and substantiallysimultaneous updating may be based on any technique available forsynchronizing and guaranteeing data update and integrity that may bestored in various memory locations.

Continuing with FIG. 11, the example method includes determining iffirst copy of default infusion schedule 70A is uncorrupted in backupmemory 62A and valid (142), which may be performed by processor 34. Iffirst copy of default infusion schedule 70A is uncorrupted and valid,IMD 12 uses first copy 70A to direct infusion of the therapeutic agent(144). If first copy 70A is found to be corrupted or invalid for someother reason, then IMD 12, e.g., using processor 34, will determine ifsecond copy of default infusion schedule 70B is uncorrupted and valid(146). If second copy 70B is found to be uncorrupted and valid, then IMD12 will use second copy 70B of default infusion schedule 70 to directinfusion of the therapeutic agent (148). IMD 12 may also update firstcopy 70A in first portion of backup memory 62A with the uncorrupted andvalid second copy 70B (150), and then use either the original secondcopy 70B or the updated first copy 70A to direct infusion of thetherapeutic agent (148). If second copy 70B is found to also be corruptor invalid for some other reason, the example method of FIG. 11 mayinclude ceasing delivery of the therapeutic agent (152) and initiatingan alarm (154), such as by processor instructing medical pump 42 to stopdelivery of the therapeutic agent and delivering an alarm message toexternal programmer 20. The method may also include periodicallychecking the first copy 70A and second copy 70B to determine if eithercopy is corrupted or invalid, and upon determining that one of thecopies is corrupted or invalid, copying the uncorrupted and valid copyto replace and update the corrupted or invalid copy.

Yet another example method of storing default infusion schedule 70 anddetecting error conditions within IMD 12 is illustrated in the flowchart of FIG. 12. The example method of FIG. 12 includes storing defaultinfusion schedule 70 on a hardware-controlled memory 56 (156), such asin hardware registers 58 shown in FIG. 2. The example method of FIG. 12further includes hardware controller 44 determining that an errorcondition wherein processor 34 or IMD software are malfunctioning (158)such that delivery of the therapeutic agent under therapy program 64 isno longer being followed. Examples of such error conditions aredescribed above and include a failure in the communication betweenprocessor and hardware controller 44, e.g., an improper handshake, or afailure of a crosschecking mechanism between hardware and software offluid delivery device 12, such as an incorrect strobing of a watchdogtimer. The example method of FIG. 12 may also include processor 34detecting the error condition, such as finding therapy program 64 orregular infusion schedule 72, 74 corrupt in memory, loss of time pointby processor 34, IMD software errors (errant pointers, memorycorruption, stack overflow, etc.), or pump reset, and communicating withhardware controller 44 the detection of the error condition by processor34. After receiving the communication from processor 44, hardwarecontroller 44 then proceeds as if it had detected the error condition byaccessing default infusion schedule 70 (162) and using default infusionschedule 70 for the delivery of the therapeutic agent (164).

If no error condition is present, hardware controller 44 continuesfollowing instructions from processor 34 and delivering prescribedtherapy program 64 (160). If such an error condition does exist, theexample method includes hardware controller 44 accessing defaultinfusion schedule 70 directly from hardware-controlled memory 56 (162),and hardware controller 44 using default infusion schedule 70 tomaintain infusion of the therapeutic agent to patient 1 (164). Theexample method of FIG. 12 may also include hardware controller 44initiating an alarm indicating the error condition is present (166),such as by activating an internal alarm device 49 (FIG. 2) ortransmitting an alarm signal to programmer 20 via telemetry module 38.

Another example method of storing default infusion schedule 70 anddetecting error conditions within IMD 12 is illustrated in the flowchart of FIG. 13. The example method of FIG. 13 includes storing a firstcopy of default infusion schedule 70 on a processor-controlled memory 36(168) and storing a second copy of default infusion schedule 70 on ahardware-controlled memory 56 (170). Storing the first copy of defaultinfusion schedule 70 (168) may include, e.g., storing first copy ofdefault infusion schedule 70A in a backup memory portion 62A of flashmemory 54, as illustrated in FIG. 4. Storing a second copy of defaultinfusion schedule 70 (170) may include, e.g., storing a second copy ofdefault infusion schedule 70B in a backup memory portion 62B of hardwareregisters 58, also as illustrated in FIG. 4.

Continuing with FIG. 13, the example method further includes processor34 determining if an error condition wherein therapy program 64 storedin main memory 60 should not be used (172), but wherein processor 34 isotherwise functioning properly. Examples of such an error condition aredescribed above and include therapy program 64 being corrupted, a lossof time point, IMD software errors (errant pointers, memory corruption,stack overflow, etc.), or pump reset. If no such error condition ispresent, processor 34 may direct that IMD 12 continue with use ofprescribed therapy program 64 (174). If processor 34 determines thatsuch an error condition is present, processor 34 may initiate an alarmindicating the error condition is present (176). Next, the examplemethod of FIG. 13 includes determining if first copy of default infusionschedule 70B is uncorrupted and valid (178).

If first copy 70A is uncorrupted and valid, processor 34 may use firstcopy 70A to direct infusion of the therapeutic agent (180). If firstcopy 70A stored on processor-controlled memory 36 is found to becorrupted or invalid for some other reason, then processor 34 may accesssecond copy of default infusion schedule 70B and determine if secondcopy 70B is uncorrupted and valid (182). If second copy 70B is found tobe uncorrupted and valid, then processor 34 may update the corrupted orinvalid first copy 70A with second copy 70B (184), and use updated firstcopy 70A to direct infusion of the therapeutic agent (186). Processor 34may also use second copy 70B directly to direct infusion of thetherapeutic agent, rather than updating first copy 70A with second copy70B and then using updated first copy 70A. If second copy 70B is alsofound to be corrupt or invalid, then processor 34 may direct that IMD 12cease delivery of the therapeutic agent (188) and initiate an alarm thatdelivery of the therapeutic agent has ceased (190).

Continuing with the example method of FIG. 13, at the same time thatprocessor 34 is determining whether an error condition exists whereintherapy program 64 stored in main memory 60 should be used (172),hardware controller 44 determines if an error condition exists whereinprocessor 34 or IMD software are malfunctioning (192). Examples of suchan error condition are described above and include a failure in thecommunication between processor and hardware controller 44 or a failureof a crosschecking mechanism between hardware and software of IMD 12. Ifhardware controller 44 determines that such an error condition does notexist, than hardware controller 44 continues following instructions fromprocessor 34 regarding delivery of the therapeutic agent (194). Ifhardware controller 44 determines that processor 34 or IMD software aremalfunctioning, hardware controller 44 accesses second copy 70B ofdefault infusion schedule 70 directly from hardware-controlled memory 56(196), and hardware controller 44 uses second copy of default infusionschedule 70B to maintain infusion of the therapeutic agent to patient 1(198). The example method of FIG. 13 may also include initiating analarm (200) that hardware controller 44 detected an error conditionwherein processor 34 or IMD software are malfunctioning and uses secondcopy of default infusion schedule 70B. The method may also includeperiodically checking the first copy 70A and second copy 70B todetermine if either copy is corrupted or invalid, and upon determiningthat one of the copies is corrupted or invalid, copying the otheruncorrupted and valid copy to replace and update the corrupted orinvalid copy.

Turning back to the example method of FIG. 8, determining that an errorcondition exists in IMD 12 (98), may include processor 34 detecting theerror condition and determining that IMD 12 cannot, or should not,continue to use therapy program 64. Examples of error conditions thatmay be detectable by processor 34 include corruption of the regulartherapy program found by processor 34 within main memory 60; a loss ofthe time point that processor 34 needs to delivery therapy program 64,such as if therapy program 64 comprises a weekly or daily schedule andthe IMD software loses the current time and/or day of the week; IMDsoftware errors that cause a reinitialization upon which processor 34cannot deliver a time-varying therapy program, such as errant pointers,memory corruption, stack overflow, or logic errors; error orinconsistencies discovered during execution of therapy program 64, suchas incorrect, inconsistent, or invalid parameters; and an unplannedreset by IMD 12, which may make delivery of programmed therapy program64 undesirable, particularly for a time-varying therapy program 64.

Determining that an error condition exists in IMD 12 (98) may alsoinclude hardware controller 44 determining that processor 34 or IMDsoftware are malfunctioning such that continuing to follow instructionsfrom processor 34 may be undesirable. Examples of error conditions thathardware controller 44 may detect that would indicate such a malfunctionmay include a failure in the timing or another defined parameter of thecommunication between processor and hardware controller 44, such as aimproper handshake, or a failure of a crosschecking mechanism betweenhardware and software of IMD 12, such as an incorrect strobing of awatchdog timer.

Determining that an error condition exists in IMD 12 (98) may alsoinclude processor 34 detecting an error condition, such as corruption oftherapy program 64 in memory, loss of time point, IMD software errors(errant pointers, memory corruption, stack overflow, or logic errors),error or inconsistencies discovered during execution of therapy program64, or an unplanned reset, and communicating with hardware controller 44that the error condition is present and instructing hardware controller44 to deliver according to default infusion schedule 70.

Although the target therapy delivery site described with reference tothe foregoing examples is proximate to the spinal cord of a patient,other applications of therapy systems in accordance with this disclosureinclude alternative delivery sites. In some examples, the targetdelivery site may be proximate to different types of tissues including,e.g., nerves, e.g., sacral, pudendal or perineal nerves, organs,muscles, or muscle groups. In one example, a catheter may be positionedto deliver a therapeutic fluid to a deep brain site or within the heartor blood vessels. In another example, a catheter may be positioned todeliver therapeutic fluid to the liver or lower torso vascular area.

Delivery of a therapeutic fluid within the brain may help manage anumber of disorders or diseases including, e.g., chronic pain, diabetes,depression or other mood disorders, dementia, obsessive-compulsivedisorder, migraines, obesity, and movement disorders, such asParkinson's disease, spasticity, and epilepsy. A catheter may also bepositioned to deliver insulin to a patient with diabetes. In otherexamples, the system may deliver a therapeutic fluid to various siteswithin a patient to facilitate other therapies and to manage otherconditions including peripheral neuropathy or post-operative painmitigation, ilioinguinal nerve therapy, intercostal nerve therapy,gastric drug induced stimulation for the treatment of gastric motilitydisorders and/or obesity, and muscle stimulation, or for mitigation ofperipheral and localized pain e.g., leg pain or back pain.

The techniques described in this disclosure, including those attributedto processor 34 and hardware controller 44 of IMD 12 and processor 26 inexternal programmer 20 may be implemented, at least in part, inhardware, software, firmware or any combination thereof. For example,various aspects of the techniques may be implemented within one or moreprocessors, including one or more microprocessors, DSPs, ASICs, FPGAs,or any other equivalent integrated or discrete logic circuitry, as wellas any combinations of such components. The term “processor” or“processing circuitry” may generally refer to any of the foregoing logiccircuitry, alone or in combination with other logic circuitry, or anyother equivalent circuitry.

Such hardware, software, firmware may be implemented within the samedevice or within separate devices to support the various operations andfunctions described in this disclosure. In addition, any of thedescribed units, modules or components may be implemented together orseparately as discrete but interoperable logic devices. Depiction ofdifferent features as modules or units is intended to highlightdifferent functional aspects and does not necessarily imply that suchmodules or units must be realized by separate hardware or softwarecomponents. Rather, functionality associated with one or more modules orunits may be performed by separate hardware or software components, orintegrated within common or separate hardware or software components.

When implemented in software, the functionality ascribed to the systems,devices and techniques described in this disclosure may be embodied asinstructions on a computer-readable medium such as RAM, ROM, NVRAM,EEPROM, FLASH memory, magnetic data storage media, optical data storagemedia, or the like. The instructions may be executed to support one ormore aspects of the functionality described in this disclosure.

This disclosure refers to illustrative examples that are not meant to beconstrued in a limiting sense. Various modifications of the illustrativeexamples, as well as additional examples in line with the disclosure,will be apparent to persons skilled in the art upon reference to thisdescription. Any specific numerical value or range described in theforegoing disclosure shall not be limiting, except for values or rangesincluded in the following claims.

The invention claimed is:
 1. A fluid delivery system comprising: a pumpconfigured to deliver a therapeutic agent to a patient; a memory storinga therapy program defining the delivery of the therapeutic agent to thepatient by the pump and a default infusion schedule based on the therapyprogram; and a processor configured to control the pump to deliver thetherapeutic agent to the patient according to the therapy program, todetermine an error condition that prevents the pump from continuing todeliver therapy according to the therapy program, and, upondetermination of the error condition, to control the pump to deliver thetherapeutic agent to the patient according to the default infusionschedule.
 2. The system of claim 1, wherein the error conditioncomprises at least one of corruption of the therapy program stored inthe memory, loss of a time point, a pump software error, a pump reset,an error in infusion parameters within the therapy program, a perceivedmalicious attempt by an external device, or a pump stoppage having aduration longer than a predetermined time.
 3. The system of claim 2,wherein the pump software error comprises at least one of an errantpointer, memory corruption, a stack overflow, an unexpected codeexecution, a memory allocation failure, an inter-processor communicationfailure, or a software exception.
 4. The system of claim 2, furthercomprising a time-measuring device, wherein the loss of time pointcomprises the time-measuring device becoming unable to reliably measurethe passage of time.
 5. The system of claim 4, further comprising asecond time-measuring device, wherein the first time-measuring devicecross-checks time measurement with the second time-measuring device,wherein the loss of time point comprises both the first time-measuringdevice and the second time measuring device becoming unable to reliablymeasure the passage of time.
 6. The system of claim 1, wherein theprocessor is a hardware-based controller, the system further comprisinga pump software processor.
 7. The system of claim 6, wherein the errorcondition comprises at least one of a malfunction by the pump softwareprocessor, a communication error between the hardware-based controllerand the pump software processor, an improper handshake between thehardware-based controller and the pump software processor, or improperstrobing of a watchdog timer associated with the hardware-basedcontroller.
 8. The system of claim 1, wherein the memory comprises atleast one of read-only memory (ROM), random access memory (RAM),non-volatile RAM (NVRAM), electrically erasable programmable read-onlymemory (EEPROM), flash memory, or hardware registers.
 9. The system ofclaim 1, wherein the memory comprises a first processor-controlledportion and a second processor-controlled portion, wherein the therapyprogram is stored on the first processor-controlled portion and thedefault infusion schedule is stored on the second processor-controlledportion.
 10. The system of claim 1, wherein the memory comprises aprocessor-controlled portion and a hardware-controlled portion, whereinthe therapy program is stored on the processor-controlled portion andthe default infusion schedule is stored on the hardware-controlledportion.
 11. The system of claim 1, wherein a first copy of the defaultinfusion schedule is stored in a first portion of the memory and asecond copy of the default infusion schedule is stored in a secondportion of the memory.
 12. The system of claim 11, wherein the firstportion of the memory is a processor-controlled memory and the secondportion of the memory is a processor-controlled memory.
 13. The systemof claim 11, wherein the first portion of the memory is aprocessor-controlled memory and wherein the second portion of the memoryis a hardware-controlled memory.
 14. The system of claim 11, wherein thefirst portion of the memory comprises a first type of memory and thesecond portion of the memory comprises a second type of memory.
 15. Thesystem of claim 14, wherein the first type of memory comprises at leastone of read-only memory (ROM), random access memory (RAM), non-volatileRAM (NVRAM), electrically erasable programmable read-only memory(EEPROM), or flash memory.
 16. The system of claim 14, wherein thesecond type of memory comprises at least one of read-only memory (ROM),random access memory (RAM), non-volatile RAM (NVRAM), electricallyerasable programmable read-only memory (EEPROM), flash memory, orhardware registers.
 17. The system of claim 1, wherein the therapyprogram comprises a therapy infusion schedule and the default infusionschedule is determined based on the therapy infusion schedule.
 18. Thesystem of claim 17, wherein the therapy infusion schedule comprises afixed infusion rate and the default infusion schedule comprises a fixeddefault infusion rate equal to the fixed infusion rate of the therapyinfusion schedule.
 19. The system of claim 17, wherein the therapyinfusion schedule comprises a time-varying infusion schedule.
 20. Thesystem of claim 19, wherein the default infusion schedule is a fixeddefault infusion rate that is equal to at least one of: an averageinfusion rate of the time-varying infusion schedule; a minimum infusionrate of the time-varying infusion schedule; a maximum infusion rate ofthe time-varying schedule; an average infusion rate for a portion of thetime-varying infusion schedule; a minimum average infusion rate from aset of average infusion rates for a plurality of portions of thetime-varying infusion schedule; a median average infusion rate from aset of average infusion rates for a plurality of portions of thetime-varying infusion schedule; a modal average infusion rate from a setof average infusion rates for a plurality of portions of thetime-varying infusion schedule; a maximum average infusion rate from aset of average infusion rates for a plurality of portions of thetime-varying infusion schedule; a minimum infusion rate in arate-selector table of the pump stored on the memory; a maximum infusionrate in a rate-selector table of the pump stored on the memory; a medianinfusion rate in a rate-selector table of the pump stored on the memory;a modal infusion rate in a rate-selector table of the pump stored on thememory; an average infusion rate in a rate-selector table of the pumpstored on the memory; an average infusion rate of an infusion history ofthe patient; a minimum infusion rate of an infusion history of thepatient; a maximum infusion rate of an infusion history of the patient;an average infusion rate for a portion of an infusion history of thepatient; a minimum average infusion rate from a set of average infusionrates for a plurality of portions of an infusion history of the patient;a maximum average infusion rate from a set of average infusion rates fora plurality of portions of an infusion history of the patient; a medianaverage infusion rate from a set of average infusion rates for aplurality of portions of an infusion history of the patient; or a modalaverage infusion rate from a set of average infusion rates for aplurality of portions of an infusion history of the patient.
 21. Thesystem of claim 1, wherein the processor is a first processor, thesystem further comprising an external programmer comprising a secondprocessor, the second processor of the external programmer beingconfigured to determine the default infusion schedule based on thetherapy program, wherein the external programmer is configured totransmit the therapy program and the default infusion schedule to animplantable fluid delivery device for storage in the memory.
 22. Thesystem of claim 1, wherein the processor is configured to determine thedefault infusion schedule based on the therapy program.
 23. The systemof claim 22, wherein the processor is configured to determine thedefault infusion schedule by software instructions running on theprocessor.
 24. The system of claim 1, further comprising a hardwaremodule for determining the default infusion schedule based on thetherapy program.
 25. The system of claim 24, wherein the hardware moduleis a hardware-based controller for controlling the pump.
 26. The systemof claim 1, further comprising an alarm device configured to provide analert upon determination of the error condition or delivery of thetherapeutic agent to the patient according to the default infusionschedule.
 27. A method comprising: determining a default infusionschedule based on a therapy program that defines delivery of atherapeutic agent to a patient by an implantable fluid delivery device;storing the default infusion schedule on a memory of the implantablefluid delivery device; determining if an error condition is present inthe implantable fluid delivery device such that the device cannotcontinue delivering therapy according to the therapy program; and if theerror condition is present, delivering the therapeutic agent accordingto the default infusion schedule.
 28. The method of claim 27, furthercomprising determining the therapy program before determining thedefault infusion schedule.
 29. The method of claim 27, whereindetermining the default infusion schedule is performed by a processor ofan external programmer, the method further comprising transmitting thedefault infusion schedule from the external programmer to theimplantable fluid delivery device.
 30. The method of claim 27, whereindetermining the default infusion schedule is performed by a user. 31.The method of claim 30, wherein the user is a clinician who determinesthe default infusion schedule based on characteristics of the patient.32. The method of claim 27, wherein determining the default infusionschedule comprises a processor determines a plurality of defaultinfusion schedules and a user selecting one of the plurality of defaultinfusion schedules determined by the processor.
 33. The method of claim27, wherein determining the default infusion schedule comprisesdetermining a fixed default infusion rate based on a time-varyingtherapy infusion schedule of the therapy program.
 34. The method ofclaim 33, wherein determining the fixed default infusion rate comprisessetting the fixed default infusion rate at least one of: an averageinfusion rate of the time-varying infusion schedule; a minimum infusionrate of the time-varying infusion schedule; a maximum infusion rate ofthe time-varying schedule; an average infusion rate for a portion of thetime-varying infusion schedule; a minimum average infusion rate from aset of average infusion rates for a plurality of portions of thetime-varying infusion schedule; a median average infusion rate from aset of average infusion rates for a plurality of portions of thetime-varying infusion schedule; a modal average infusion rate from a setof average infusion rates for a plurality of portions of thetime-varying infusion schedule; a maximum average infusion rate from aset of average infusion rates for a plurality of portions of thetime-varying infusion schedule; a minimum infusion rate in arate-selector table of the pump stored on the memory; a maximum infusionrate in a rate-selector table of the pump stored on the memory; a medianinfusion rate in a rate-selector table of the pump stored on the memory;a modal infusion rate in a rate-selector table of the pump stored on thememory; an average infusion rate in a rate-selector table of the pumpstored on the memory; an average infusion rate of an infusion history ofthe patient; a minimum infusion rate of an infusion history of thepatient; a maximum infusion rate of an infusion history of the patient;an average infusion rate for a portion of an infusion history of thepatient; a minimum average infusion rate from a set of average infusionrates for a plurality of portions of an infusion history of the patient;a maximum average infusion rate from a set of average infusion rates fora plurality of portions of an infusion history of the patient; a medianaverage infusion rate from a set of average infusion rates for aplurality of portions of an infusion history of the patient; or a modalaverage infusion rate from a set of average infusion rates for aplurality of portions of an infusion history of the patient.
 35. Themethod of claim 27, wherein the implantable fluid delivery deviceincludes a processor for controlling infusion of the therapeutic agent,wherein determining the default infusion schedule is performed by theprocessor.
 36. The method of claim 27, wherein the memory is aprocessor-controlled memory.
 37. The method of claim 27, wherein thememory is a hardware-controlled memory.
 38. The method of claim 27,wherein storing the default infusion schedule on the memory comprises:storing a first copy of the default infusion schedule in a first portionof the memory; and storing a second copy of the default infusion in asecond portion of the memory.
 39. The method of claim 38, wherein thefirst portion of the memory is a first type of memory and the secondportion of the memory is a second type of memory.
 40. The method ofclaim 27, further comprising storing the therapy program on the memoryof the implantable fluid delivery device.
 41. The method of claim 40,wherein the default infusion schedule is stored on a first portion ofthe memory and the therapy program is stored on a second portion of thememory.
 42. The method of claim 41, wherein the second portion is aprocessor-controlled memory.
 43. The method of claim 41, wherein thefirst portion of the memory comprises a first type of memory and thesecond portion of the memory comprises a second type of memory.
 44. Themethod of claim 27, further comprising initiating an alarm upondetermining that the error condition is present or delivering thetherapeutic agent to the patient according to the default infusionschedule.
 45. A non-transitory computer-readable storage mediumcomprising instructions for causing a programmable processor to:determine a default infusion schedule based on a therapy program thatdefines delivery of a therapeutic agent to a patient by an implantablefluid delivery device; store a default infusion schedule based on atherapy program that defines delivery of a therapeutic agent to apatient by an implantable fluid delivery device on the computer-readablemedium; determine if an error condition is present in the implantablefluid delivery device such that the device cannot continue deliveringtherapy according to the therapy program; and if the error condition ispresent, deliver the therapeutic agent according to the default infusionschedule.
 46. A fluid delivery system comprising: means for delivering atherapeutic agent to a patient; means for storing a therapy programdefining the delivery of the therapeutic agent to the patient by themeans for delivering the therapeutic agent; means for storing a defaultinfusion schedule based on the therapy program; and means forcontrolling the means for delivering the therapeutic agent to thepatient; means for determining an error condition that prevents themeans for delivering the therapeutic agent to the patient fromcontinuing to deliver therapy according to the therapy program; whereinthe means for controlling the means for delivering the therapeutic agentto the patient directs delivery of the therapeutic agent to the patientaccording to the default infusion schedule when the means fordetermining an error condition determines that the error condition ispresent.
 47. The system of claim 46, wherein the means for storing atherapy program comprises at least one of read-only memory (ROM), randomaccess memory (RAM), non-volatile RAM (NVRAM), electrically erasableprogrammable read-only memory (EEPROM), or flash memory.
 48. The systemof claim 46, wherein the means for storing a default infusion schedulecomprises at least one of read-only memory (ROM), random access memory(RAM), non-volatile RAM (NVRAM), electrically erasable programmableread-only memory (EEPROM), flash memory, or hardware registers.
 49. Thesystem of claim 46, wherein the therapy program comprises a therapyinfusion schedule and the default infusion schedule is determined basedon the therapy infusion schedule.
 50. The system of claim 49, whereinthe therapy infusion schedule comprises a continuous infusion rate andthe default infusion schedule comprises a fixed default infusion rateequal to the continuous infusion rate of the therapy infusion schedule.51. The system of claim 50, wherein the therapy infusion schedulecomprises a time-varying infusion schedule.
 52. The system of claim 51,wherein the default infusion schedule is a fixed default infusion ratethat is equal to at least one of: an average infusion rate of thetime-varying infusion schedule; a minimum infusion rate of thetime-varying infusion schedule; a maximum infusion rate of thetime-varying schedule; an average infusion rate for a portion of thetime-varying infusion schedule; a minimum average infusion rate from aset of average infusion rates for a plurality of portions of thetime-varying infusion schedule; a median average infusion rate from aset of average infusion rates for a plurality of portions of thetime-varying infusion schedule; a modal average infusion rate from a setof average infusion rates for a plurality of portions of thetime-varying infusion schedule; a maximum average infusion rate from aset of average infusion rates for a plurality of portions of thetime-varying infusion schedule; a minimum infusion rate in arate-selector table of the pump stored on the memory; a maximum infusionrate in a rate-selector table of the pump stored on the memory; a medianinfusion rate in a rate-selector table of the pump stored on the memory;a modal infusion rate in a rate-selector table of the pump stored on thememory; an average infusion rate in a rate-selector table of the pumpstored on the memory; an average infusion rate of an infusion history ofthe patient; a minimum infusion rate of an infusion history of thepatient; a maximum infusion rate of an infusion history of the patient;an average infusion rate for a portion of an infusion history of thepatient; a minimum average infusion rate from a set of average infusionrates for a plurality of portions of an infusion history of the patient;a maximum average infusion rate from a set of average infusion rates fora plurality of portions of an infusion history of the patient; a medianaverage infusion rate from a set of average infusion rates for aplurality of portions of an infusion history of the patient; or a modalaverage infusion rate from a set of average infusion rates for aplurality of portions of an infusion history of the patient.
 53. Thesystem of claim 46, further comprising means for alarming upondetermination of the error condition or delivery of the therapeuticagent to the patient according to the default infusion schedule.